Considerations and Best Practices When Back Promoting

Updated 1 week ago by Copado Solutions

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 of the back promotion. For example, if you have promoted a user story from dev1 to UAT, this user story will be available for back promotion to dev2 or other lower environments, but it won’t be available for back promotion to dev1.
  • 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 of the back promotion.
  • 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).
  • The Status of the Promoted User Story record must be Outdated.The Status field enables you to make user stories available again for promotion or back promotion when you manually move them to the environment where they originated in order to fix something and recommit. This field can be manually changed to Active if you accidentally change the environment on a user story and don’t want to make it available again for promotion/back promotion. Only those user stories whose Promoted User Story status is set to Outdated will be available for back promotion.

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.

Best Practices

  • Schedule a date and a time for the back promotion so that your team of developers knows when the process will be taking place.
  • If you are back promoting user stories after having refreshed a sandbox based on your production environment, leverage the Last Refreshed Date field on the Environment record. This way, you won’t have tons of user stories ready to be back promoted since Copado’s user stories ahead and behind calculation won’t include those already in production before the sandbox refresh.

How did we do?