How to push Work-In-Progress Back to Refreshed Org

Overview

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? 

Let’s take as an example this pipeline:

User-added image
 
The different strategies you can follow will vary depending on the environment the user stories where you have committed the work in progress reside in, so first of all, answer the following questions:
  • 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.
Now that you know which option you need to follow depending on your circumstances, let’s take a look at the step-by-step process for each of the options.

Option 1: Back Promoting Changes (Best Practice When Available) 

 
Use case: You should choose this option if you are back-promoting changes from a sandbox with multiple sandboxes pointing to it (e.g. Integration).

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.

Steps:
  1. Create a list of user stories you would like to sync back to the refreshed Dev1 and Dev environments.
  2. Open the Pipeline Manager.
  3. On the Pipeline page, click on Mass-Back Promote
  4. Select a source environment (Integration) and a project.
  5. Click on Disable Auto Selection Overwrite and select the user stories you would like to back-promote to the refreshed sandboxes Dev1 and Dev2:

Disable Auto Selection Overwrite button
 

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!

  1. Click on Back Promote & Deploy.
 
Note: If you just want to back-promote your user stories to other lower environments (not the ones they originated from) you can do that by changing the Status picklist on the User Story Promotion record from Active to Outdated:

User Story Promotion Status field


Option 2: Fake Promotion/Back-Promotion

Use Case: Someone in your team made a change directly in Staging, contrary to best practices, but those changes have not yet reached Production. Dev1 and Dev2 have been refreshed and you need to get the changes made in Staging back into Integration and into the refreshed Dev1 and Dev2 environments.

Steps:
  1. 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)

Important note: It’s not possible to deploy field-level security for nested components with this option.

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.

Steps:
  1. Determine the branches you would like to deploy from and make a list of those branches: Example: feature/US-0000029.
  2. From the org where copado is installed, navigate to the Git Repository record tied to your active pipeline. 
  3. Click on Retrieve Commits:
 
Retrieve Commits button
 
 
  1. Type in or copy & paste the name of the feature branch in the pop-up window.
  2. Click on Submit to retrieve all the commits tied to the feature branch. 
  3. 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.
  4. Fill in the branch field with your branch name and then click off the branch in the white space.
Note: This will filter by the branch and show the commits that are on the branch. You will see a lot of commits, this is because it is showing all the commits from the master branch as feature branches are created off the master branch.
  1. Review the commits with the commit message of your user story:
List of commits
 
  1. For Initial Commit, select the oldest commit with your user story number in the commit message (lowest one on the screen).
  2. For End Commit, select the newest commit with your user story number in the commit message (highest one on the screen).
  3. Click on Create Deployment.
Note: Please note that it may take a while for the deployment to be created.
  1. Navigate to the Deployments tab.
  2. Look for a deployment with the name Git Deployment and click into that deployment.
  3. Update the name of the deployment (e.g Best Practice = “User Story Name → Sandbox Name + short message”).
  4. Select the org where you want to deploy the changes (e.g. Dev1) as the To Org.
  5. Delete any Delete MetaData steps that get created - you have already completed your destructive change by refreshing the sandbox.
  6. 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.
  7. Click on Deploy and then Deploy All.
To keep the org branch in sync with the org, you will need to perform some additional steps:  
  1. If you chose this option three, and there are nested components, you may need to log into your sandbox and add them again.
  2. Open the user story. 
  3. Click on Commit Changes and select the Recommit Files Git operation. 
  4. Set the Re-create Feature Branch checkbox to true.
  5. Make sure to include any nested components you recreated in bullet 1 above
  6. Click on Commit Changes
This will recommit the files that you just deployed to the org and update the org branch, so it is in sync with the org.

How did we do?