Provide better dev/prod system integration

[du5tin]

We have several customers with very large SCADA systems that are worked on by multiple integrators. We have a test/dev system setup and on the network with a production setup. We do our development on the test system and then export our changes and import on the production system.

This usually goes well and without much trouble. However, if some integrators don't follow a proper change management procedure (e.g. updating a template on test but forgetting to update it on production) then the two databases will drift over time. In an effort to reduce our admin and change management workload it would be excellent to be able to develop and test on the dev system and then have a "promote changes to prod" feature.

As an extension of this process it would be good for the system to evaluate parent objects (templates, embedded mimics) for changes and publish those to production before publishing any inherited objects. This could have a dialogue box similar to the delete dialogue. "Publishing to production will impact the following objects and make the following changes:" and list the impacted objects with the parent objects first and inherited objects last. 

Further expansion on the idea: have the ability to have a configuration field to prevent publishing certain objects. There are some cases where we always want test/production objects to be different. E.g. communications settings, system headers, etc..

[paudel]

I really like this idea.

[BevanWeiss]

It is a good idea 🙂

Although I think with DB authentication / authorisation differences between the Test/Dev and Production system it might be troublesome.

 It would also need to have ViewX type (i.e. Client) connections between the Test/Dev and Production systems, which can lead to some issues.

I did have an idea at some time for a 'Synchronise with remote system' 'object' (i.e. an extension of the CGroup object).  Such an object would maintain a local 'cached' copy of the CGroup in the 'child' database, but could be configured to prevent any changes to items beneath it, with all of those items being synchronised (not necessarily in real-time, but based on some configurable update rate) with the 'parent' database from a matching CGroup object (i.e. the !Config folders could be kept in sync across all systems from some master DB).

It wouldn't solve the Test/Dev situation, but it would solve the divergence issue... since it would not be possible for such integrators / users to modify synched items in these folders.

[sbeadle]

Thank you for these suggestions, they will feed into our roadmap.

Best regards

Steve