This article is prepared by our Salesforce Developer Ivan Zubarevich.
In this article, I will tell you a bit about my experience with Gearset, one of the most popular Salesforce DevOps tools these days. It allows your Salesforce team to easily compare and deploy metadata and data between Salesforce environments, back up your orgs, monitor, and roll back changes. It can be connected to a version control system (VCS) like Azure or Git and can compare, push and pull changes between VCS and selected Salesforce org. Let's dive a bit deeper.
Gearset Metadata Deployment general overview
Gearset Metadata Deployment feature is a key tool for your team to be able to compare, analyze and promote changes between environments. In order to run a comparison, define the source and target environment (e.g. between a sandbox and production, or between sandboxes). Gearset lets you compare and deploy between any two environments: Salesforce orgs, local files, or Git branches. You can even create a new scratch org or Git branch from the UI. You can add more than 100 types of metadata to comparison, there are some standard metadata filters already available by default which can be leveraged based on the comparison needs.
When comparison is built you will see the list of metadata and diff viewer, which allows you to click items in the comparison tabs to see the difference between environments, in detail. Here you can choose changes you want to be propagated to the target env. There is even a possibility to select separated lines of Apex code (pilot)! You can also refresh your comparison or add more metadata types in it if you forgot to include them initially.
The next step is validation and analysis. Here you can observe issues encountered during auto-validation and suggested fixes, provided by the Gearset platform to make deployment more likely to succeed.
Next is the summary screen, where you can find the total list of changed items, add names for your deployment and deployment notes, assign links to Jira, Azure or Asana tickets and even execute some Apex as a post-deployment step.
After a successful deployment, Gearset will generate a detailed PDF of the changes in the deployment, also you will be able to find all Gearset deployments in the Deployment History section.
There are plenty of additional features related to the creation, validating and promotion process in Gearset like deployment schedules, draft and data deployments, destructive changes promotion, roll back and data backup, and all of them are interesting and worth a separate article, but today we're going to talk about the Continuous Integration feature (which actually inspired me to write this article).
There are plenty of additional features related to the creation, validating and promotion process in Gearset like deployment schedules, draft and data deployments, destructive changes promotion, roll back and data backup, and all of them are interesting and worth a separate article, but today we're going to talk about the Continuous Integration feature (which actually inspired me to write this article).
Continuous Integration
Gearset continuous integration jobs can automatically validate and deploy changes between environments, and identify issues between deployments or they can be continuous validation-only jobs. Some examples are below:
Continuous integration job is basically a bridge between 2 instances, source and target, and they can be Salesforce orgs, BitBucket, GitHub or Azure repositories. They use webhooks (which will be automatically created by Gearset after job's creation) to update the target every time the source is updated.
There is an option to disable a particular continuous integration job if you don't need it. Every continuous integration job has a history, where you can find all commits merged to the target, download a report with the results or even roll back changes if you need it.
Nevertheless, the continuous integration job is only a single point in the DevOps pipeline, and for the flow to work it must be connected to other instances. And that's where Gearset Pipelines come into play.
Gearset Pipelines is a part of Gearset continuous integration that helps you visualize, manage and analyze your DevOps pipeline. I will tell you more about this awesome feature using one of my testing pipelines, and we use similar flows on our Gearset projects. So, here is the test pipeline:
This is a typical working example of the Gearset Pipeline. Looks self-explanatory, right? Each of these environments I created based on a particular continuous integration job, for example Dev1-SyncTest environment is nothing but a continuous integration job, where the source is a BitBucket branch Dev1-Sync and the target is a Salesforce org, the name of which is blurred due to extreme secrecy.
Here you can find environments related to 2 Dev Salesforce orgs, 1 QA, PPR and one Production Salesforce org as well as to respective branches in your VCS. Pipeline can be mentally divided into 5 stages, let's get more info about them.
Here you can find environments related to 2 Dev Salesforce orgs, 1 QA, PPR and one Production Salesforce org as well as to respective branches in your VCS. Pipeline can be mentally divided into 5 stages, let's get more info about them.
1 - Developer sandbox instances. These environments are directly related to your developer orgs and are used to create and promote feature branches.
2 - DEV-Sync static environments. They are used to synchronize changes from your feature branches to your developer orgs and allow you to back-propagate changes from other branches to your developer sandbox.
3 - QA-Sync static environment. Used to promote changes to QA Salesforce org.
4 - PPR-Sync static environment. Used to promote changes to PPR Salesforce org.
5 - PROD-Sync static environment. Used to promote changes to Salesforce Production org.
2 - DEV-Sync static environments. They are used to synchronize changes from your feature branches to your developer orgs and allow you to back-propagate changes from other branches to your developer sandbox.
3 - QA-Sync static environment. Used to promote changes to QA Salesforce org.
4 - PPR-Sync static environment. Used to promote changes to PPR Salesforce org.
5 - PROD-Sync static environment. Used to promote changes to Salesforce Production org.
To promote changes through the pipeline developer creates a new feature branch in VCS (it's possible to do this even from the Developer sandbox instance on the Gearset Pipeline page), adds and commits his changes to the branch (it's easy using Gearset Metadata Deployment feature I've described above), and then create a Pull Request against the next stage in the pipeline. Here is the picture of the created Pull Request from Dev1 against QA org.
In Pull Request details you can see that the gearset did a conflict check and validation of new changes for you automatically. All you need is to push the 'Promote Changes' button and magic will happen!
But wait a minute, it's not all the magic, after promotion to QA two(!) more Pull Requests will be created automatically. One for PPR for further deployment and another one for back-promotion to Dev2 environment, to keep Dev1 and Dev2 in sync.
But wait a minute, it's not all the magic, after promotion to QA two(!) more Pull Requests will be created automatically. One for PPR for further deployment and another one for back-promotion to Dev2 environment, to keep Dev1 and Dev2 in sync.
Now the developer responsible for Dev2 just needs to click one button and his org will be synchronized with the latest QA changes from Dev1. There is also an option to create back-promotion Pull Requests only after deployment to Production. It's highly recommended to do back-promotions to your Dev org as often as you can, to keep your metadata synced with the most recent changes.
Every time you move your changes through the pipeline validation and conflict checking will be executed against the next environment in the pipeline. As an example, here Gearset notifies you that auto-resolving of conflicts cannot resolve the issue, so you need to resolve conflicts by yourself.
Every time you move your changes through the pipeline validation and conflict checking will be executed against the next environment in the pipeline. As an example, here Gearset notifies you that auto-resolving of conflicts cannot resolve the issue, so you need to resolve conflicts by yourself.
After clicking on the 'View and resolve conflicts' button, you will see a handy list of highlighted differences between your fresh changes and existing data on the target environment.
You can Accept feature changes, keep Environment ones, or even select and keep both of them. Then just push the 'Commit merge' button and Gearset automatically will add a new commit to your feature branch, validation will be rerun automatically, and you will be able to promote your changes to the new stage.
When it comes to Production deployment, other than standard one-feature deployment you can use Gearset Release functionality, where you can select a few feature branches, unify them as one mini-project deployment using the 'Create Release' button, and push to production as a single set of changes.
When it comes to Production deployment, other than standard one-feature deployment you can use Gearset Release functionality, where you can select a few feature branches, unify them as one mini-project deployment using the 'Create Release' button, and push to production as a single set of changes.
There are plenty of customizable settings in Gearset Pipelines, from selecting test classes for validation and hotfix functionality to adding contact information to receive notifications about each deployment. It will take forever to describe them all here, so you can get a free trial and check them all out.
There is still some functionality I'm eager to see, like pre-deployment and post-deployment steps (it was partially released, like post-deployment Apex execution, but not for pipelines at the moment), Pull Request review functionality and some ownership improvements. I also faced some bugs, for example, Remote Site Settings are not deployed to any environment in my pipeline, without any explanation. But maybe I’ve done something wrong, and I just need to contact Gearset support. BTW Support team in Gearset is awesome, they answer in a few minutes in support chat and try their best to resolve your requests as fast as they can. You can even create a meeting with a Support team representative and invite some Gearset core specialists to attend it, and they will carefully take all your thoughts about the current issue, propose solutions and mark it as a potential future development. And they are all very positive, sometimes you may want something to be broken, just to talk to them.
There is still some functionality I'm eager to see, like pre-deployment and post-deployment steps (it was partially released, like post-deployment Apex execution, but not for pipelines at the moment), Pull Request review functionality and some ownership improvements. I also faced some bugs, for example, Remote Site Settings are not deployed to any environment in my pipeline, without any explanation. But maybe I’ve done something wrong, and I just need to contact Gearset support. BTW Support team in Gearset is awesome, they answer in a few minutes in support chat and try their best to resolve your requests as fast as they can. You can even create a meeting with a Support team representative and invite some Gearset core specialists to attend it, and they will carefully take all your thoughts about the current issue, propose solutions and mark it as a potential future development. And they are all very positive, sometimes you may want something to be broken, just to talk to them.
At the end, I want to say that Gearset Continuous Integration is a great holistic solution for your team if you want to have all your DevOps activities in one place, with proper visibility, easily managed and totally understandable workflow that helps to keep all your environments in sync.