versiondog ExportModule

The ExportModule is an optional add-on for the versiondog system. It provides you with an easy way to export data and reports from versiondog. The information can be exported at any chosen time and organized in importable file formats (CSV/XML). This straightforward and open method of data exchange creates numerous possibilities for cross-operability between versiondog and the other systems and software that you have in place, maximizing your opportunities to analyze your data and optimize your processes.

Defining and automating exports and the processing of exported information is quick and straightforward. The following examples are two common customer use cases for the ExportModule. Perhaps they will inspire you to think of others.

This production KPI can be generated from a cyclical export that looks for job runs where there is a difference between the latest version of the programming project on the server and the program currently running on the device.

Exported information:

• The last job run where the server version and backup were equal
• Number of job runs since the last time the server version and backup were equal
• Number of uploads and/or comparisons with errors (following changes to firewall configuration etc.)

The next step is to process the information so that it becomes a useful performance indicator and present it in an easily-comprehensible form. You could use, for example, a traffic light system:

• Green (status normal) -> differences/errors persist for < 1 week (probably normal maintenance work etc.)
• Yellow (warning) -> differences/errors persist for > 1 week (server version might be out of date etc.)
• Red (critical) -> differences/errors persist for > 4 weeks (no action taken yet following previous warnings)

It is recommended that users apply a lock state to components when they are working on them. This prevents other users from working on them at the same time and removes the potential for versioning conflicts.

Lock states are set in the UserClient or EasyClient. When other users see a lock state, they know that they need to wait until a new version is checked in or the lock state is removed before working on the project. The lock state comment gives them additional information.

Sometimes users forget that they have applied a lock state to a component and are in fact not editing the project at all. This wrongly prevents other users working on the project.

• How can an administrator find out whether all the lock states applied to components are still required?
  An administrator can open the UserClient and filter according to lock state in the component overview, then contact each user individually. This is extremely time consuming!

• How can the Export Module help?
  An export of component lock state data can be linked to an automated emailing function that sends emails to the users concerned containing information such as:
  • The path to components that they have locked
  • Which lock state is applied
  • How long it has been applied
• This data can then also be periodically made available to the administrator in the form of a summarized report.