Parallel Releases Use Case
Parallel Releases with Different Cadence Challenges
The major release is scheduled to be released after the minor releases and patches (hotfixes) as it takes significantly more time. This scenario happens recurrently through the year.
To isolate changes, each project is developed by different teams on isolated environments.
At the moment, the major project, v2.0, is ready to be released. The production environment is ahead by several versions of the minor releases that have not been back ported to the v2.0 team, and as a consequence, v1.1 is not part of v2.0 codebase. The v2.0 project sandboxes are behind by all v1.1 user stories.
Since the major project is not aware of the minor development, deploying the long-term project presents big integration challenges and a high risk of overwriting previous deployments.
Solution: Back Merging the Minor Releases into the Major Releases
First part: Integrate changes from short term into long term
Second part: Integrate long term into short term
Once the major project is ready to be released:
Parallel Releases with Different Cadence Strategy
By following the back merging process, higher releases, such as v2.0, will only be ahead of production and not behind as user stories from minor releases will be already part of their codebase.
This will eliminate the chances of overwriting changes, will reduce conflicts, will enable a real integrated testing and will increase the speed of the release.
- Work with Copado releases:
- Create a mayor Release record for the long-term project and set a version for it, e.g. v2.0.
- Create a minor Release record for the short-term project and set version for it, e.g v1.2:
- After the major release, the short-term project base version could become v2.1, however this is not technically required.
- Filter the mass back promotion based on the release. In order to filter what user stories to back promote, make sure you filter through the Release record on the Pipeline page:
- Define the governance process and follow it with no exceptions.
- Resolve Git merge conflicts in the promotion branch ONLY and not directly in the integration/uat environment.
- Only perform changes in development environments (dev and hotfixes) and not in UAT or production.
- Schedule mass back promotions on a daily basis.