Requirements: Essentials Plus, Work Items

Optional: CI Jobs

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

As part of a Work Item, deployments made to your target environment from a team member's org can be highlighted after enabling the Back Deployment feature. By notifying the user of past deployments made to the target environment, the option to ensure their source is in sync with upstream environments has become even easier.

By clicking on the number of deployments, a popup will appear, showing the specific deployments that were made to the target environment that your source is missing. These deployments can then be collectively back deployed using the "Back Deploy" button below. Alternatively, if these do not need to be back deployed, you can select to "Ignore All" to dismiss the notification. 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.

Once "Back Deploy" has been selected, a single deployment will be generated that contains all metadata included in the listed deployments. This selection will identify what is new and/or changed relative to your original source environment, and allow you to deselect any particular components you do not want to back deploy.

Instead of being notified that your source is out of sync when starting a Work Item, you also have the option to proactively address the situation. By using the Org Compare feature under the Organizations tab, you can select your source environment in the dropdown at the top of the screen, then see how many deployments behind each of the target environments below are. For example, "Int Org" has been selected in the Org dropdown, and of the orgs listed beneath, "Developer Sandbox" is missing 4 deployments that were made to "Int Org". When "Back Deploy" is selected, these 4 deployments are displayed and can be back deployed in a single action to "Developer Sandbox".

Teams can also take advantage of a back deployment pipeline to quickly move changes from Production to Developer environments. This method is not only beneficial for bringing changes that originate downstream to upstream 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 deployment 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.

A final method of back deployment 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 Plus can help to prevent that headache and take care of automating back deployment on your behalf.

In conjunction with regularly backing up your source environment to Git, Copado Essentials Plus 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 deployment 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 Plus 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.