Best Practices for Deployment Management in a Multi-Developer Environment

I am seeking advice on best practices for deployment management in a scenario where multiple developers are involved. Our goal is to ensure a smooth transition from the testing environment to the production environment with permission isolation. Here are some specific points and questions I have:

  1. Multiple Projects on a Single Server: We are running multiple projects on one production server, so restoring the entire Gateway is not feasible. What are the best practices for deploying individual projects without affecting others?
  2. New Project Deployment vs. Maintenance Modifications:
  • For a brand new project, it seems straightforward to export the project from the testing environment and import it into the production environment. After this, we can delete the project from the testing environment to avoid any accidental operations.
  • However, for projects that are already in maintenance mode, what is the best approach to deploy modifications? Should we follow the same export-import process, or are there other recommended methods?
  1. Server-Level Modifications: How can we efficiently import and export server-level modifications such as translations, icons, and pictures? Is it necessary to manually replicate all these changes in the production environment, or is there a more streamlined approach?
  2. Project-Level Modifications: Currently, it appears that importing and exporting projects can handle most of the project-level modifications. Are there any limitations or considerations we should be aware of?
  3. Ensuring System Synchronization: What strategies can we employ to ensure that both the testing and production environments remain synchronized? Are there any tools or practices that can help maintain consistency between the two environments?
  4. Device Connection in Testing Environment: If the testing environment is connected to the same devices as the production environment, it can cause anomalies. What are the best practices to avoid such issues? Should we use simulated devices or a different approach?

I appreciate any insights or recommendations from the community on how to effectively manage deployments in a multi-developer setup. Thank you in advance for your help!

* Cough * wait for v8.3...

5 Likes

Q: How many developers?
Q: How many projects?
Q: What level of Factory Acceptance Testing is required for which changes? - Is there a written procedure that needs to be followed in order to update the size/color of a font on a page?
Q: How many remote gateways are planned? Edge or Full?

If the plan is to start with one project & a couple of developers - and grow organically, then I would start as simple as possible, and let the version control grow organically as well.

A starting point:
https://www.docs.inductiveautomation.com/docs/8.1/tutorials/tutorials-and-helpful-tricks/development-server-best-practices

Assuming organic growth

  • Co-developers will need to communicate.
  • Developers (or their project manager) should define which changes are able to be deployed directly to Production server vs Dev server (w/ testing prior to deployment).
    • Consider export / import only as few resources as required for modification. If only a single view is being modified, then migrate only that view between servers - minimize the likelihood for regression.
  • Within a project, the Designer app will attempt to alert co-developers which screens are open by which developer. Developers should be aware of potential for stepping on others and should communicate where overlaps exist.
  • Developers should never be working on the same group of tags at the same time (I'm not aware of native methods for knowing what tags are being edited by which developer).
  • Try to use project inheritance where it makes sense to.
  • In order to view 'live data' on a dev gateway, consider an OPC UA connection (read-only) from a development gateway to the production gateway. Optionally, use Ignition's Simulation device. Try to avoid a connection to a production PLC on the development server.
  • For testing R/W capability (proper FAT) from Dev server, invest in a test bench controller, on an isolated network, with same logic as facility controller. Add any simulation logic required there.
  • In a distributed architecture, use Enterprise Administration. <-- Strongly Recommend! Automatically push specific project resources (or entire projects) to remote gateways. Automatically back up all gateways to a central server...

In general, I've had minimal grievance using built-in tools for developing on production gateways & deploying to remote gateways (using EAM), also no complaints migrating resources between gateways via export/import.

1 Like