Versioning

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 production 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. 
   
• 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

With Ignition there are ways 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. Two main ways to control your project versions are:

• 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.
• Versioning software: Ignition stores it's files in a simple to use format on the hard drive. This allows you to use whatever versioning software that you like to create a system to track changes and roll back as needed.

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.