How to push Work-In-Progress Back to Refreshed Org
This article describes three different options you have for moving work in progress back into a refreshed sandbox.
This can be very helpful, for instance, if you have work in progress and your sandbox is refreshed. Suppose you have committed this work in progress to a user story, and the user story has not moved through the pipeline all the way to Production. In that case, you can follow the steps for one of the three options provided in this article to recover these changes and restore them to your sandbox.
Let’s take a look at the three different options you have to accomplish this. But before we move on, check out the article Sandbox Refresh and make sure to follow the steps provided in that article if you have refreshed a sandbox.
Which Option Should I Follow?
- Are the user stories in an environment with more than one sandbox pointing to it like the Integration environment in the pipeline above?
- Yes: Go for option 1.
- No: Answer the next question.
- Are the user stories in the lowest environment, that is Dev1 or Dev2 in the pipeline above?
- Yes: Go for option 3.
- No: Go for option 2.
Option 1: Back Promoting Changes (Best Practice When Available)
In our example Use Case, the lowest environments, Dev1 and Dev2, have been refreshed, but your user stories were already deployed to Integration, and have not already been deployed to Production, therefore they are not included in refreshed Dev1 and refreshed Dev2 Sandboxes anymore. So now you want to push those user stories that were only deployed part-way through the pipeline from integration back into Dev1 and Dev2.
- Create a list of user stories you would like to sync back to the refreshed Dev1 and Dev environments.
- Open the Pipeline Manager.
- On the Pipeline page, click on Mass-Back Promote.
- Select a source environment (Integration) and a project.
- Click on Disable Auto Selection Overwrite and select the user stories you would like to back-promote to the refreshed sandboxes Dev1 and Dev2:
Note: Clicking on Disable Auto Selection Overwrite enables you to back-promote user stories to both refreshed Dev1 and refreshed Dev2 environments, including to the same environment they came from originally!
- Click on Back Promote & Deploy.
Option 2: Fake Promotion/Back-Promotion
- Follow the steps in the article How to Back Promote a User Story Created in a Higher Environment and use Staging as the org credential.
Option 3: Deploying a Single User Story from a Branch (Available for More Scenarios)
Use Case: You have committed changes to user stories over the last month, but your user stories still lie in Dev1 and haven’t been deployed to Integration. Dev1 has been refreshed from Production and you need to get work in progress from the user stories back to Dev1.
- Determine the branches you would like to deploy from and make a list of those branches: Example: feature/US-0000029.
- From the org where copado is installed, navigate to the Git Repository record tied to your active pipeline.
- Click on Retrieve Commits:
- Type in or copy & paste the name of the feature branch in the pop-up window.
- Click on Submit to retrieve all the commits tied to the feature branch.
- Once the feature branch commits have been retrieved (you may need to reload the page, but you will see them in the latest commits), from the same page, click on Create Deployment.
- Fill in the branch field with your branch name and then click off the branch in the white space.
- Review the commits with the commit message of your user story:
- For Initial Commit, select the oldest commit with your user story number in the commit message (lowest one on the screen).
- For End Commit, select the newest commit with your user story number in the commit message (highest one on the screen).
- Click on Create Deployment.
- Navigate to the Deployments tab.
- Look for a deployment with the name Git Deployment and click into that deployment.
- Update the name of the deployment (e.g Best Practice = “User Story Name → Sandbox Name + short message”).
- Select the org where you want to deploy the changes (e.g. Dev1) as the To Org.
- Delete any Delete MetaData steps that get created - you have already completed your destructive change by refreshing the sandbox.
- Click on the magnifying glass icon on the Git MetaData step and uncheck the excess - worry only about the metadata that was created or updated for the feature branch.
- Click on Deploy and then Deploy All.
- If you chose this option three, and there are nested components, you may need to log into your sandbox and add them again.
- Open the user story.
- Click on Commit Changes and select the Recommit Files Git operation.
- Set the Re-create Feature Branch checkbox to true.
- Make sure to include any nested components you recreated in bullet 1 above
- Click on Commit Changes.