Versioning in Ignition

When we talk about versioning in Ignition, there are two main things that come to mind: Software versions and Project versions.

Project Versions: Here we are referring to the current and previous states of your project in Ignition. You might have a test server with a development project in addition to the currently running projection server. As you make changes and improve your project, these might get out of sync, or you may want to roll back to a previous good state after a failed test of new changes. Ignition has several ways to keep track of these versions for you.
Software Versions: Here we are talking about the versions of installed software. What version of Ignition you are using, what version(s) of Java are installed, your database version, etc. This is important to keep track of because backups from one version may or may not work on other versions depending of the type of software or company that makes it.

While they may seem similar, it's important to keep these distinctions in mind while you are developing. Both have considerations that can effect the success of your project.

Project Version Considerations

In Ignition there are several tools to keep track of your projects and give you the ability to easily test new changes or go back to a previous stable revision when you need to. The three main ways to control your project versions are:

Published vs Staging Modes: Ignition allows you to have a separate staging mode to preview changes before publishing them to the Clients. This is a great tool for testing any changes before deploying them to users.
Project Rollback: There is rollback feature built into the Designer that will revert any changes made and saved to a previous version of your project. This system also uses the Commit Message system to label individual versions.
Making and Restoring Backups: We always recommend that you create backups regularly, and you can easily restore them to go back to a previous known stable version of your project.

On this page ...

Published vs Staging

Each project can have two distinct versions at the same time: the Staging version and the Published version. Having a published version and a staging version allows you to make changes to a project, save the changes, and test out the changes before "publishing" it to a production environment.

By default, a new project is configured to be in Auto publish mode, which means that the two versions are always identical. However, if you change a project to be in Manual publish mode, you can then explicitly publish a project in the Designer.

Usually, Vision module Clients run the published version of a project. However, by launching a Client in a special mode (from the Designer or from the Config section of the Gateway), you can launch a Client that runs the staging version of that project. This staging Client will receive updates on every save, where the production Clients receive updates only on publish. This lets you test out your changes to the project in an actual Client, which is more realistic than the Designer's preview mode.

Not all aspects that comprise a project use this system. It is primarily intended for systems such as the Vision module's Clients. Features that run persistently on the Gateway, such as Tags, the SQL Bridge's Transaction Groups, and Gateway-side scripting always run the most recently saved changes (the Staging version). Since these features by definition must run in exactly one place, they cannot be effectively "tested out" by simultaneously running a staging version alongside a published version.

In the Designer, choose the Project > Properties menu item, then go to the Project > General page to set the Publish Mode. By default, a new project is configured to be in Auto publish mode, however you can change it to Manual publish mode.

In the default Auto mode, when you want to save your project, Designer lets you do a File > Save and Publish, which means both the Staging and the Published versions will be the same and identical.

In Manual mode, when you want to save your project, Designer lets you do both a File > Save or a File > Publish. File > Save updates the Staging version, and File > Publish updates the Published version.

Publish Selected Resources

It is also possible to publish individual resources on a project as they are finished instead of publishing the entire project. This is particularly helpful when there are multiple people working on the same project. If you want to get resource updates to users quicker rather than waiting for the whole project to be ready to publish. To learn more, refer to Saving and Publishing Projects.

Project Rollback

Each project keeps a log of recent changes. A new entry is made any time you save or publish, and the user, time, affected resources, and a commit message are logged. At any time, you can roll back to one of these previous versions. Ignition keeps track of the previous 10 saved versions of your project. You can select any one of these versions to restore with the roll back feature.

To restore a previous version of your project

In the Designer, select File > Rollback.
The Rollback window is displayed showing the edit dates, user name, edit count, and edit type.
Select the version you want to roll back to and click Rollback.
On the Confirm dialog box, click Yes.
The Designer reloads the selected version of the project.

Making and Restoring Backups

We recommend always making backups to protect your project in the case of a server failing, but these backups can be used directly as another roll-back mechanism for your projects or the whole Gateway. This is not ideal however, as backups are primarily designed for disaster recovery. By restoring, you will lose any changes you've made since the last backup was collected.

Software Version Considerations

Ignition Version

It's important to have a good idea about what software versions you are using, but we make it simple. Ignition only allows one version at at time to be installed on a computer. This means that you never have to worry about which version you are using at the moment. Ignition versions are made up of three numbers: the Platform, major, and minor version numbers. For example, 7.8.2 is platform 7 (Ignition), major version 8 (new features), minor version 2 (stability improvements).

If you want to know what version of Ignition you are using, there are several places you can find it. The two simplest places to find your Ignition version are in the Gateway Webpage and in the Designer . Both of these also list the version of Java that the Ignition service (Gateway) is using. Note: this may not be the only version of Java that is installed.

The Gateway Webpage: in the Configure section under System -> Status. There is also a modules page under Configuration -> Modules that will tell you the versions of each module.
In the Designer: In the Menubar under Help -> About Ignition Designer. This page will tell you the version of the platform (Ignition) as well as each module.

Ignition backups will work on any version that is the same or newer. For example, a backup taken from 7.7.0 can be restored in 7.8.2, but the opposite is not true. If you are developing on a test server, make sure that they have the same version of Ignition so your backups can be transferred seamlessly.

Java Version

You can have multiple Java installations (all different versions) on one computer. Java uses version number similar to Ignitions. For example, Java might be version 1.8.0_45 but we often refer to Java as "Version 8 Update X." In this example, the 1 means Java, and it is version 8.0 update 45. The best way to check what Java versions are installed depends on your Computer's operating system, but in Windows you can open up the control panel and click the Java option. If you have multiple versions of Java installed, check the Ignition version (above) to see which Java version is being used. If Ignition is using the wrong one, you can easily Change your Java Version. Depending on your OS and Java version, your Control Panel might look slightly different than this:

images/download/attachments/6035080/java_version.png

Database Version

It is not uncommon to connect Ignition to multiple types and versions of Databases, but it is very rare to have multiple versions of a database installed on the same computer. Usually you will see multiple servers handling the load of multiple databases. Fortunately the Ignition drivers for connecting to a database don't work for specific versions, they will work for all database versions. Just pick out the right type (MSSQL, MySQL, Oracle, etc.) and the driver will do the rest. Check out the Database Connections section for more information on getting conected.

Using Separate Production and Development Servers

Once you complete your project and have it in production, it is a good idea to have a separate Ignition development server for making future changes. That way, the changes will not affect the plant floor and can be completely tested before rolling out to the production environment. It is also recommended to have a development server to perform any Ignition upgrades so any problems can be addressed before moving to a production environment.

Considerations

There are a few things to consider when having a production and development server. First, the development server should have its own PLCs and SQL databases. You do not want the development server to point to the live PLCs because it would be possible to accidentally write values to PLCs that may start or stop equipment. Likewise, you do not want the development server to point to the production database or else you may risk duplicating data.

Second, the development server does not need a license because you can run the server in its two hour trial mode. Of course you can get a second license for longer testing periods if you need to.

Third, you should never move a Gateway backup from the development server to the production server. If done right, the development server is pointing to the development PLCs and databases. If you move the Gateway backup, these connections will be saved inside the backup and restored on the production server. Which is bad because the production server should be pointing to the live PLCs and databases. Instead you should backup individual projects and tags separately to move them to the production server. Ignition projects use database connections and tags but are connected only by name. This means the production and development servers can have the same PLC and database names, but behind the scenes they will point to different places.

When you restore a project to the production server, remember the projects contain the windows and the templates and not the Tags and other global resources. You will have to transport the Tags and other changed items in addition to the projects. See Gateway vs. Project Backups for more information on what is included in each type of backup.

Enterprise Administration Module

The EAM allows you to control multiple Gateways from one central location, but can also be used for version control. It has the ability to push resources from one gateway to another, and this can be applied to a production/development system. You can create tasks that will push your changes at the click of a button. See the Enterprise Administration section for more information on sending projects.