Managing conflicts between release vehicles
Release Vehicle conflicts occur when multiple teams deploy the changes related to the shared rules of an artifact in parallel, causing later releases to become outdated if earlier releases reach production first. Concurrent Change Management (CCM) detects these changes and restricts the affected release vehicle from proceeding further, and requires regeneration to incorporate the latest production updates.
CCM prevents release vehicle conflicts when multiple teams work on changes simultaneously. Release vehicle conflicts arise when one release vehicle contains changes affected by a recently deployed release vehicle. When that happens, the system either automatically handles the conflict, or provides clear indicators to users to guide the appropriate response.
U+ Bank promotes a Premium credit card through its website. Following market research, the bank has decided to update several aspects of the card. The marketing team requests a new email treatment, the strategy team needs to edit an engagement policy, and the product team wants to modify attributes. Due to different approval timelines and business priorities, these modifications are organized into three separate release vehicles. The treatment change is scheduled for the first week in release vehicle 1 (RV-1), the engagement policy for the second week in RV-2, and the attributes for the third week in RV-3. All three change requests modify shared rules, which create the potential for conflicts during deployment.
An ideal deployment sequence
In an ideal deployment sequence, the Release Manager follows a structured workflow. They test RV-1 in the business operations environment, generate the release vehicle, deploy it to the User Acceptance Testing environment for validation, and then move it to production. Once RV-1 reaches production, the Release Manager repeat this same sequence for RV-2, followed by RV-3. Throughout this process, CCM automatically handles the merging of changes. The system ensures that changes from RV-1 merge into RV-2, and subsequently, changes from RV-2 to RV-3. This automated process maintains consistency across all release vehicles as they progress through each environment toward production deployment.
When conflicts occur
However, real-world deployment scenarios often deviate from this ideal sequence. When extensive testing requirements exist for a particular release, RV-2 may need to be generated and moved to the UAT environment before RV-1 completes its journey to production. This then creates a conflict, where RV-2 is generated without incorporating the changes from RV-1. When RV-1 subsequently deploys to production and updates the system of record, RV-2 becomes outdated because it lacks these newly deployed changes. This situation triggers the conflict detection mechanism within CCM.
To prevent merge conflicts from reaching production, the system blocks the release manager from advancing RV-2 to production until the conflict is resolved, and then immediately alerts the release manager that RV-2 has a conflict and that it requires regeneration to incorporate the recent production changes. The system displays a clear warning message:
Resolving the conflict
As a Test Manager, you reject the release vehicle to remove it from the test environment. Then, as a Release Manager, open the release vehicle and return it to the Plan stage, which unlocks the release vehicle so that you can regenerate it. The Release Manager then moves the release vehicle to the Generate stage, where the system regenerates the rules by accommodating the latest changes from production. After you complete the regeneration, you can deploy the release vehicle to the test environment, where testing teams validate the combined changes before final deployment to production. Once the testing is successfully completed, the Test Manager can approve the release vehicle and later deploy it to production.
This conflict resolution process applies to any situation where two release vehicles contain changes to shared rules and one deploys after the other is generated. This systematic approach ensures that all changes remain synchronized.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
¿Quiere ayudarnos a mejorar este contenido?