Parallel Releases Use Case

Updated 3 months ago by Copado Solutions

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 

  1. Constantly deploy user stories from the minor releases project to the integration and testing environments.
  2. Run all quality gates in the integration and testing environments.
  3. After testing, use the mass back promote functionality to back promote/back merge all user the stories that belong to the minor project into the major project. v1.1 into v2.0

Once the major project is ready to be released:

  1. Deploy to UAT and preprod.
  2. Run all tests and quality checks.
  3. Validate complete release into production.
  4. Use a mass back promotion to back promote all the user stories of the major project into the environments of the minor project.
  5. Deploy to production.   

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.

How did we do?