This article explains how to get your features back-propagated through your Gearset Pipeline into the lower (static) environments.
By lower environments we mean specifically your long-lived Git branches, which are the source environments of your CI jobs - in the context of Gearset Pipelines.
Why is back propagation needed in Pipeline workflows?
Salesforce environments constantly change as you build features, deploy them, and release them to your production org.
Sometimes a hotfix is what you need to release quickly, and skipping parts of the release pipeline is needed. Over time, more and more metadata differences between your environments begin to appear.
Being able to back propagate (or back promote) features eases the task of aligning changes across all environments. And, most importantly, it allows developers to work from the most relevant code.
Ultimately, it leads to encouraging more frequent releases and reduces the likelihood of experiencing environment drift and overwriting work.
In promoting your first features article we guide you on how to forward propagate your changes with our Pipelines solution.
Let’s now look at how you can get your orgs synced and automatically make merged changes available for promotion to lower environments in the Pipeline.
The logic is simple: Gearset allows you to forward and back propagate, automatically creating (but not promoting) PRs on your behalf.
The way you can do this depends on what you’re trying to achieve. Before you go ahead, consider the steps we describe below.
Where do I want changes to be back propagated to?
Back propagate Pull Requests (or Merge Requests - in GitLab) from Main/Master branch to lower, long-lived, environments in the Gearset Pipeline.
For more information, read the section below:
Sync lower static environments (except Developer Sandboxes)Update Developer Sandboxes with changes already pushed to Main/Master branch.
If you're interested in updating your Dev Sandboxes, please refer to this article for further guidelines:
Back propagation Legacy workflow - for information on how to start using Dev Sandbox Updates feature, please check:
Migrating from legacy back propagation to Developer Sandbox UpdatesBelow in this article (see section) we also recommend not to use the legacy back propagation workflow with the new "Dev Sandbox Updates" feature.
Sync lower static environments (except Developer Sandboxes)
If your team does hotfixes and needs to get them back propagated to other (lower) Pipeline environments, but doesn't necessarily need to refresh metadata in Dev Sandboxes, then a setup similar to Pipeline shown on image below is required.
The tool automatically back propagates changes if they were to be merged straight into higher environments.
Example: A new PR opened from Hotfix
environment, and promoted through the Pipeline by merging it into Main
, would automatically create back propagation PRs into lower static environments (highlighted in green) - in this case UAT
and INT
.
If a PR is merged directly into Main
branch (i.e. outside the Pipeline), it would also back propagate this change into UAT
and INT
(again only the static environments highlighted in green).
Recommended back propagation set up for your Pipeline
The recommended back propagation set up is to configure the Gearset Pipeline to create back propagation pull requests Only when changes are promoted into the final environment.
Click the cog icon: on the Pipelines UI page to find this setting.
A short video to show this option in Edit pipeline
settings:
Sync lower environments (including Developer Sandboxes)
Gearset allows you to enable updates directly to your Dev Sandboxes. This way you can back propagate (or back promote) changes directly to your Pipeline's Sandboxes.
You can decide which Sandbox in the pipeline to enable updates for. To do it, simply click on a given Sandbox and then select the three dots icon:- you'll then see a dropdown menu with Enable updates
option.
A short video to demonstrate the setting:
Important to note: We strongly recommend to use Dev Updates feature when your Pipeline settings are configured to create back propagation pull requests only when changes are promoted into the final environment (see below photo).
What recommendation applies if I'm still using the legacy back propagation workflow?
If you're still using Gearset's legacy back propagation workflow (which creates PRs from Main/Master back to your feature branch instead of updating Dev Sandboxes directly), e.g. because you may have not yet migrated to the new Updates workflow, depending on your use case it may be advised to create back propagation PRs "when changes are promoted into any adjacent environment".
However, this is not a recommended option with the new Updates functionality!
What does the setting "Only when changes are promoted to final environment" mean?
Configuring your Pipeline this way means that if you promote changes from one Dev Sandbox into to next environment in the Pipeline (e.g. INT
), or in fact into any further static environment in the Pipeline (e.g. UAT
), you are not yet triggering back propagation of the changes to any lower static environment.
This is simply because the changes begin to be back propagated to lower static environments only after being merged in Main/Master branch (and released in Production).
This is because a best practice and our recommendation is that you aim to have these changes tested and merged into Prod before they're being back propagated.
What's the default behaviour?
Back propagation initiates after a PR is merged into the Master branch in your Pipeline.
That's when automatic PRs are opened simultaneously against any lower environments in the Pipeline (the environments highlighted in green).
Note: Back propagation PRs are opened only against lower environments that don't yet have the changes that were merged into the Main/Master branch.
Back propagation PRs are not automatically merged into the lower environments - this is a manual step that you need to take by selecting Promote changes
button.
Explanation of the setting "When changes are promoted into any adjacent environment"
This options means that if you promote changes from any Developer Sandbox into the next environment in the Pipeline (e.g. INT
), the back propagation to other Sandboxes in the Pipeline will be initiated.
At the same time, after the PR is successfully merged into the INT
, it also forward propagates to UAT
.
Back propagation will only happen to those Sandboxes that have the Enable updates
option activated.
Remember that back propagation happens only to the static environments or Dev Sandboxes that don't yet contain the promoted changes.
Note: When we refer to "back propagation" in the context of Dev Sandboxes, we mean Gearset's new Dev Updates functionality.
More info on this feature in our documentation on:
Getting started with Developer Sandbox Updates in Pipelines
Potential benefits of this configuration
The main benefit of working this way is that changes sync up a lot quicker in lower environments. However, this can create more noise within your Pipeline.
This way of syncing may allow developers working on new changes in their respective Sandboxes to get access to the latest features and user stories promoted through the Pipeline before these features/stories reach the Production.
Keep in mind: As mentioned earlier, Gearset does not recommend this way of utilising back propagation.