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 back-propagation pull requests for each feature merged into the release, which would need to be deployed into each environment 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.

Over the next few weeks we will be moving to back-propagating releases as a single PR. This will mean that feature back-propagation PRs will no longer be created on your environments, and release back-propagation PRs will be created instead (containing all changes from features merged into that release, as well as any additional conflict resolution). All feature deployment steps, tickets and other settings associated with your features will be attached instead 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.

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.
​

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.