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.
Don’t forget to check out: Salesforce Deployment Using Gearset: All You Need to Know
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).
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.
Check out another amazing blog here by Vimera: Salesforce Spring’24 Updates for Admins
This article is prepared by our Salesforce Developer Ivan Zubarevich. To continue reading and read about Gearset Pipelines, please visit our website.
