Big Picture User Experience
As an MoC administrator who is promoting a package between zones, I need the option to disable the old value check before promoting, or override the check should a mismatch be detected. I need this because there are many reasons why the 2 zones Databases are not in sync, and when the promotion fails it creates extra re-work, and can leave the system in a worse state than before.
Background
Currently, during the promotion of a package, if the system detects that the current value of a field in the destination zone doesn't match the previous value in the source zone, the promotion is aborted. This is known as the "old value check".
Additionally, when the Old Value Check fires, the system will try to automatically rollback the package. If that fails, which is does often, the destination system is left in a state that is more divergent from the source than before.
Together, these two symptoms create a large effort for the user to re-sync the two systems, and clean-up any mess on the destination.
This is especially true when deleting points
Detailed Description
It shall be possible to promote the package with an option to override the "Old Value Check". Ie, if the old value is not the identical to the value that is expected, with the provided the command line argument the MoC agent shall be able to promote the package regardless.
With this type of promotion, The user will be prompted that a "old value" was encountered and RollBack will not be possible. Or the very least the roll back will restore the value that is defined/excepted old value. The goal is that rollback would never be dis-allowed.
Business Value
Management of Change is an essential tool for customers with a stringent change management process. Customers report that it is not possible to ensure that the production (destination) systems stay perfectly in sync with the T&D (source) systems.
When the current old value check fires, it can actually create greater problems adding the effort to resolve, especially when combined with other reported issues with the MoC Auto-Rollback, the effort quickly multiplies.
Ultimately, the root cause is the systems are out of sync. There are several reasons for this:
MOCkey is unique on the various systems. Customer is working to synchronise these
Updating fields that operators have modified. i.e. 'jello data'
-
Field work creating lots of DB edits. No knowing in advance which fields are going to be problematic (e.g. collect, devpathjoin, watchdog, ACE)
e.g. User relocates a point to a different watchdog and discovers that they can't until the point is moved to the remote. Now, they can't move the points back because the old remote doesn't exist anymore.
e.g. User creates a point and an ACE routine on System A. Then the point is moved to System B, but not the ACE routine, which stays on System A. So, they disable aceconfig in the dev/test zones, but now these zones are significantly different to prod. This is particularly hard to fix because you cannot change the dataset of a aceconfig record.
re-configuring relationships between points leads to users finding new sequence-of-step requirements that mean they need to reverse what they've started, but can't due to finding even more new sequence-of-step requirements, which result in a user being trapped in a Catch-22 situation
The larger point is that users don’t know in advance which fields are going to be problematic
The additional work needed to sync the destination and source is seen as low-ROI (they just get out of sync again) low-priotity (still outstanding following handover from SRP to Ops). This is expected to change once MoC is more reliable (will help to keep systems in sync) and the Ops team are able to prioritise the work.
This is seen as the #1 MoC issue to solve for Enbridge.
