Important Announcement: Protecting our Community from Spam Events
Dear Members, we apologize for any disruption or inconvenience caused by the
recent spam incidents, and we want to assure you that our dedicated team is
actively investigating each reported instance of spam and implementing robust
measures to mitigate the impact. Learn more on
Spams Mitigation Guidelines
Schneider Electric Community Team
Provide better dev/prod system integration
EcoStruxure Geo SCADA Expert Ideas
Use this portal to submit your innovative ideas to make Geo SCADA Expert of greater value to you and to the SCADA & Telemetry community at large. Every idea will be individually reviewed and evaluated by our team for merit and feasibility and will be listed with its current status for other community members to see.
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..