When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.

Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.

Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the release branch - what's on the release branch is what should be deployed.

Without getting into that argument, I'll try to describe what happened during my deployment window and how I think it can be improved.

I can't stress this enough, everything on the release branch was correct and ready to go to PROD. The method of applying changes to feature branches that were already on the Release appears to be the root cause of the issue in Gearset.

Now the outcome that I want to avoid is what happened after I clicked the Deploy/Promote button on the Release in the Gearset UI.

1. Click Promote
2. Release is Validated and Apex Tests passed in PROD
3. Release disappears from Gearset UI
4. PRs start to open against PROD and UAT, many more against PROD than UAT though.
5. PR Validation Jobs start running against PROD
6. PR Validation Jobs end a considerable time later
7. Deployment of the actual release begins

It was only after the deployment into my PROD environment that I realized what had happened. And I had to learn it by smoke testing in PROD and piecing that together with the newly opened PRs against PROD.

What I finally understood was that the package deployed for my release was not the contents of my release branch, but rather my release minus a handful of UAT feedback changes. These UAT feedback changes were made on the same feature branch and followed the same pipeline process as any other request, but because they had already been added to the release the additional changes were tracked separately inside of Gearset.

Because this was tracked separately within Gearset, this needs to shift left. Teams shouldn't be surprised by this kind of change to their release in the midst of their deployment window. If Gearset determines that a feature cannot go in the release, that should happen before I click the promote button during my deployment window.