Do you see unexpected differences in your Pull Requests (PRs)?
A common issue some of our customers face when using pipelines is they see unexpected differences in their pull requests.
There are several reasons why these differences appear. For a detailed technical explanation of this behavior see this article:
Are your Pull Requests not showing what we expected?
As a best practice when using Gearset Pipelines feature, we recommend syncing up all environments to your default base (main/master) after each release to Prod - this is to prevent issues such as you seeing additional and unexpected items in your PRs.
Most common use case
When a feature is promoted through the entire Pipeline and reaches Main, it will cause a drift in terms of commits between Main and the other long-lived environment branches (for example SIT and UAT).
This is due to the fact that the PRs are always opened from the original feature branch, so the merge to the UAT branch will have a different number from the merge to Main, even if it will include the same items.
The Git provider (GitHub, GitLab, Azure etc.) compares your branches based on the number of commits, not based on the actual items deployed - the consequence of this is that after a merge to Main, when a user creates a new feature branch from Main, it may appear that the next environment (e.g. UAT branch) is behind one or more commits. It means that if we work on a new feature, for example a new field, the PR to the next environment will not only include the commit(s) we made to add the new field to our feature branch, but also all the commits that were previously merged to Main before the feature branch was created.
This is not a huge issue in terms of the actual deployment to the target org, because the automated CI job will find out that those items have already been previously deployed to the target (e.g. UAT org). However, it might be confusing for the user to see unexpected items included in the PR targeting the UAT branch.
In Gearset Pipelines, we offer a shortcut to create a PR from the Main branch targeting the environment branches. By merging this PR, the 2 branches will be again in sync (meaning that: all the commits that have been done in Main will be replicated in the environment branch).
Below screenshot shows a Sync PR ("sync pull request") feature in the Pipeline. You can trigger it by selecting Create pull request (blue button).
This creates the Sync PR within your Pipeline. Sync PR will show up against your selected environment branch, so that you can Promote it:
The Sync PR will include all commits that Main is ahead of UAT.
This has to be done for each environment branch, as the Sync PR does not get automatically propagated upstream and downstream in Gearset Pipelines, like a normal PR.
Another use case
The Main branch is the source of truth, but sometimes it might happen that something gets added to Prod before Main (for example a Hotfix, a parallel deployment process outside Pipelines).
Sometimes a user needs to add to Main metadata types that were not previously included in Version Control. The user then commits these items to Main, that will drift apart from the other long-lived environment branches (Main would be ahead of UAT for example).
If we create a new feature branch for a new "feature A", when the time comes to open a PR against the next environment (e.g. UAT), this PR will also include every commit that was added to Main directly.
The solution to this issue is:
To click on the
Create sync pull requestbutton from the last environment of your Pipeline:
Then create sync PRs from main to all your static environments:
Important to note: Some static environments are not listed when opening the sync feature for all environments. They'd not be listed if they already have an open sync PR.Similarly, you'll get this failure message if a given static environment is already up to date:
Failed to open sync PR: There are no commit differences between the environment <nxxx> and "gs-pipeline/main_-_<xxx>". The environment <xxx> is already up to date.- where<xxx>in this context refers to an environment name (see an example of the error message on below screenshot).
Promote the sync PR opened against every environment. By merging this PR, the 2 branches will be again in sync (all the commits that have been done in Main will be replicated in the environment branch).
Are you adding new metadata types to Main?
If so, then be aware that the filters in the CI jobs need to be updated accordingly or the automation will not see those changes and will not deploy them to the target org.
More information on adding missing metadata types to your Pipeline can be found here:
Adding previously missing metadata types into Gearset pipelines
Will the Sync PR overwrite work in progress in that environment?
Let's say that in your Pipeline, two developers are working out of two separate feature branches, but each containing the exact same custom field component. The first dev has promoted their changes to the custom field all the way to Production. The second dev however, has only reached the penultimate environment (Staging). If you were to trigger and merge the Sync PR, can we expect the second devs custom field to be overwritten?
Not automatically, no. We would expect this to trigger a merge conflict within your Pipeline. In this particular example, you'll be presented with a warning and an option as to which custom field changes you'd like to maintain(either those from the first dev or the second). You never have to worry about the accidental overwriting of components.