How do things work currently?
Previously, when you deployed a release into your production environment, we would update your upstream environments using per-feature back propagation. This would create feature promotion pull requests for each feature merged into the release on every previous environment, which would need to be deployed one-by-one.
We found that for some users this caused a significant number of pull requests to be created for each deployed release, so we have been working to improve this behaviour going forward.
What is changing?
Over the next few weeks we will be moving to back-propagating releases as a single PR. This will mean that when a release is deployed, feature back-propagation PRs will no longer be created on your environments, Instead, release back propagation PRs will be created (containing all changes from features merged into that release, as well as any additional conflict resolution done for the release itself). All feature deployment steps, tickets and other settings associated with your features will be attached to the release back-propagation PR itself.
Back-propagated release PRs will appear in the PR list on the environment itself, in the same way that feature PRs appear currently.
How will this affect you?
For most customers this change should not impact your processes. When updating upstream environments you will now only need to deploy one PR as opposed to one PR per feature in the release.
However, any existing custom integrations or logic that relies on releases being back propagated as individual features need to be updated to support this new flow.
Are there any known limitations?
Currently, we will not back propagate deployment steps associated with the bundle PR itself - this behaviour matches previous behaviour for deployment steps, but is something we are working on addressing.
FAQs
If I deploy 3 individual feature PRs to Main, will it open separate back propagation pull requests for all 3 PRs, each in the previous environments?
Yes, the behaviour for deploying individual features PRs is unchanged. They will be bundled in a single PR only if they are in a release.
I merged a release containing 10 feature pull requests. How does it back propagate?
It will be back propagated as a single PR for each previous environment. So, if there are 7 previous environments to which the changes should be propagated, 7 new PRs will be created (instead of 7x10 PRs as it was in the previous workflow).
What changes will a back propagated release PR contain?
It will contain the changes from all features as they were deployed as a part of the release. In addition to that, if any conflict resolution was performed between the features when they were merged into the release, these changes will also be included in back propagation.
Does this change how development sandbox updates work for release PRs?
No, the updates are based on changes merged into the Main branch and this is not affected by the new back propagation mechanism.
Feedback
If you have any questions about bundle back propagation, feel free to contact us in the In-app chat.