Skip to main content
Version: 7.9

Development Server Best Practices

Overview​

Many users find a Development Server useful so changes can be tested in a safe environment before being pushed to production. This page details several recommendations and issues to consider when utilizing a Development Server.

Device Considerations​

  • The Development Server should have its own PLCs. This prevents the Development Server from accidentally writing to a Tag that the Production Server is connected to.
  • Device connection names should be the same on both the Development and Production Servers. OPC Tags typically reference the name of the Device Connection in their OPC Item Path, so using the same name on both servers means that Tags can easily be migrated from one server to the other.
  • Using PLC simulators is an alternative to the Development Server having its own PLCs. Generally this means finding simulators for your specific devices outside of Ignition.

Licensing Considerations​

  • The Development Server does not require a licensed Ignition Gateway, but one may be necessary depending on your testing requirements. All modules can run on the trial for a two-hour testing window, and may be started an unlimited number of times. If you want a more flexible test system for your Development Server, you can add a license to it.

Database Considerations​

  • The Development Server should have its own database, separate from the production database. This is especially useful when designing screens that manually modify a database table. For more information, see our Database Connections page.
  • The names of the database connections used by the Development Ignition Gateway should match the names of the connections on the Production Server. Many system functions that interact directly with the database, such as system.db.runPrepUpdate, take the name of the database as a parameter, so using similar names for connections on both servers means you will not have to modify the script once it has been moved to the Production Server.

Network Considerations​

  • Some users prefer to place their Development Server on a separate network from the Production Server. This way there can be no confusion as to which server is being accessed. Keep in mind that Clients can only be launched on panels/computers that have network access to the host Gateway, so how this development network is configured will impact where testing clients can be launched. For more information, see our Gateway Nework page.
  • If you are restoring a copy of your Production Server on your Development Server, you will need to be cautious: two copies of the same gateway, on the same network, will both have access to all PLCs and Databases. In this case it is possible for duplicate historical records to be generated, amongst other potential problems. To prevent this, we recommend keeping the Development Server on a separate network. Alternatively, you could utilizing the Restore Disabled checkbox when restoring on the Development Server. Once the disabled Development Gateway is up and running, you can edit each connection and point them to testing equipment.

Transferring Resources from Development​

  • When you are ready to move resources from the Development Server to the Production Server, Gateway Backups should not be utilized as they will include connections to the development resources. Instead, use the Project Exports and Tag Exports functionality to transfer resources.
  • In cases where there are multiple Ignition Servers (Production or Testing), the Enterprise Administration Module can make the resource migration easier.

Cloning a VM​

Sometimes it may be useful to clone a VM running an Ignition Gateway to keep all the configurations the same in the new system. However, there are a few things to keep in mind when doing this.

  • The cloned VM should be isolated from the network at first. Especially when you have a Gateway Network setup with multiple Gateways communicating with each other or Tag History being stored to a database, having two Gateways with the same name and IP address can cause problems for a system which won't be able to differentiate between the two.
  • The new VM should be given a different IP address. If you have a static IP address setup for the VM, the clone should get its own unique IP address.
  • The Gateway System Name needs to be changed. This is done by going into the Gateway Webpage, navigating to the Gateway Settings page in the Configure section, and changing the System Name to be different. Note, that this name should be different from all Gateways in the network, and is important when using Tag History, as the Gateway name helps the historian system differentiate multiple Gateways storing to the same database.
  • Within the data folder located in the Install Root, there is a file titled ".uuid". This file needs to be deleted. Once it has been removed, the Gateway can be restarted, which will automatically generates a new file.
  • After all of the points above have been handled, the VM can then be hooked back up into the network and used like a new Gateway.
Last updated on by ia-sshamgar