Considerations and Best Practices When Back Promoting
What Can Be Back Promoted?
Not all user stories can be back promoted. The criteria used by Copado to determine the user stories that can be back promoted to a destination environment is as follows:
- The user story should not have been already promoted from the destination environment.
- The user story should not have been previously back promoted to the destination environment.
- The user story should have been deployed at least once to a higher environment.
- The user story needs to be sitting in a higher environment with regard to the destination environment.
- The user story cannot be flagged as ‘Excluded from CBM’ (if the Exclude From CBM checkbox is checked, that user story will not be included in the count of user stories ahead and behind).
Risks When Back Promoting
When you make changes in your sandbox but do not commit and deploy them to the next environment, you might lose these changes. Since Copado uses Git as a source of truth, and the process to reflect your metadata changes in Git is achieved through the commit action, your work might be overwritten by your release managers if they back promote some changes to your sandbox, and you have not committed your work. To avoid this, all changes should be committed before back promoting user stories to lower environments.
- Schedule a date and a time for the back promotion so that your team of developers knows when the process will be taking place.
- Only back promote user stories that have been tested and approved. The user stories that are going to be back promoted should have passed quality gates such as manual, unit and regression testing.