Standard in VTScada Development Runtime Licenses
Rolling back helps you move forward with confidence.
It is increasingly impractical to shut down modern mission-critical SCADA systems for configuration. Developing on live systems has the added benefit of allowing you to work with real I/O. Application Version Control (AVC) provides the freedom to configure in real-time in a multi-developer environment knowing you can instantly roll back any change.
Easy-to-use features allow you to:
- See a full change history of the application
- Identify incremental changes made in each version
- Recover instantly from unexpected effects of configuration
- Merge changes in a multi-developer environment
Note: AVC tracks application configuration changes rather than VTScada product versions.
Change Records and the Version Log
The AVC Version Log (above) allows authorized users to oversee changes on all servers from any workstation running a VTScada Development Runtime license. The log also tracks the version running on each computer.
Deploy Changes Manually or Automatically
By default, configuration changes are automatically deployed to all networked servers. These changes can be applied to un-networked servers using VTScada ChangeSet files. This can easily be disabled so that changes are only applied locally until users choose to deploy them. A local (L) version is generated and displayed in the version log (e.g., WorkstationName-L9). On deployment, users enter a comment (e.g., “Added station graphics”) and a Deployed Change Record is created.
Traceability
Each change record includes a version number, date/timestamp, the user who made the changes, the workstation used, and a comment. An administrator may drill down into the Version Log to see details of all incremental changes made in any version (Image 2). A color-coded legend identifies the ‘from’ and ‘to’ states of each change. If Automatically Deploy is ON, the ‘D’ versions include incremental changes. If it is OFF, the ‘L’ version includes these changes.
Switching Versions
Should deployed changes negatively affect the application, an administrator can undo them by selecting a previous version in the Log and switching to it. The selected version is duplicated and becomes the current version.
Reverse Version Changes (Rollback)
Reversing a version change creates a new version of the application and removes all changes from a specific revision and avoids having to redo changes made after that revision.
Merge Version Changes
When rolling back to an earlier version, later changes can be re-introduced by merging versions. For example, if you have switched from version 10 to 5, you may select specific changes from version 7 and merge them back into the application.
Distributed Version Control
VTScada uses Distributed (not central) Version Control. Changes can be made, viewed and undone anywhere, regardless of whether you’re connected to the network or even on a plane.
Built-in Beats Bolt-on
AVC is a core VTScada feature ensuring airtight integration over the life of your system. Configuration changes affecting multiple files are done atomically, guaranteeing consistency in every revision.
Flexible Licensing
VTScada applications automatically include change history. Access to the version log is standard with Development Runtime licenses and optional for Runtime licenses. If you don’t enable AVC on your Runtime, your integrator can access your change history if they have a System Integrator license.
Note that VTScada Version Control is used to maintain versions of specific applications rather than VTScada core product releases.