All Collections
Setup and Integration
Back Promotions with Copado Essentials+
Back Promotions with Copado Essentials+

Utilize these tips to make sure your developer environments always have the latest changes.

Garrett Meeks avatar
Written by Garrett Meeks
Updated over a week ago

Requirements: Essentials+, Work Items

Teams that are taking advantage of multiple developer environments to better partition their work load will likely encounter scenarios where they need to pull newly promoted changes into their own environments. Instead of the manual task of scouring upstream environments for recent changes to pull back as part of an org-to-org deployment, Copado Essentials+ has several ways that we can help to minimize the effort of bringing those changes downstream.

Quickly Back Promote from Within a Work Item:

As part of a Work Item, successful deployments can easily be back promoted to other developer environments through the use of the Back Promotion feature.

This functionality will use the current stage in the Work Item as the source, allowing you to choose the desired target environment and pre-populate a Deployment with all of the related metadata.

This Deployment can then be shared with the appropriate team member for review and back promotion when they're ready, to avoid prematurely overwriting any in-progress work.

Use a Back Promotion Pipeline for Bulk Back Promotions:

Teams can also take advantage of a Back Promotion Pipeline to quickly move changes from Production to Developer environments. This method is not only beneficial for bringing changes that originate upstream to lower environments, but can be an effective method to sync all of your sandboxes without needing to go through the tedious process of a sandbox refresh. Setting up a Back Promotion Pipeline is an easy task, which can be achieved by simply setting Production as the starting point from your pipeline and adding your environments in reverse order. For teams with multiple Developer environments, this pipeline can end at the last shared environment, and individual deployments can be used to sync the respective Developer environment with the last stage in the pipeline.

Automated Back Promotions Utilizing Git:

A final method of back promotion would be to automate this task through the use of CI Jobs and a Git repository. Having multiple developer environments that need the latest changes from upstream requires several independent deployments, carefully curated to ensure that only the net differences are being deployed and that any in-progress work is not overwritten. Fortunately, Copado Essentials+ can help to prevent that headache and take care of automating back promotions on your behalf.

In conjunction with regularly backing up your source environment to Git, Copado Essentials+ can help to automate this otherwise repetitive task by deploying the net differences between two Git branches to a Salesforce environment. This process involves the creation of two types of CI Jobs: one that is scheduled to perform a full backup of a source (or developer) environment, and another that is triggered using a webhook to deploy the net differences between any two Git branches you select. The diagram below shows a visual representation of an automated back promotion for "SF Dev1", which, through using Work Items and CI Jobs, is pulling recent upstream changes that came from "SF Dev3".

To setup a scheduled backup of your source environment, take a look at this guide on CI Jobs. As for setting up a CI Job to deploy net differences, you'll need the Git branch you want net differences from to be set as the source of the CI Job, with the Salesforce environment receiving these differences as the target. Once selected, choose "Deploy" as the Action and follow the steps listed here to properly setup the associated webhook in your Git repository.

After specifying the details of the job, within the "Deploy Options", under Git source, select the option to "deploy differences between [source branch] and [target branch]". With this option, the target/comparison branch will need to be specified manually, but should be the branch that is associated with the target Salesforce environment.

Once saved, any changes that are deployed to the source branch will then trigger the webhook, activating the the CI Job. This will cause Essentials+ to compare the branches specified in the CI Job and deploy the net differences between them to the target Salesforce org listed in the details of the CI Job.

Did this answer your question?