Getting Started With Gearset

Unless you’ve been living under a rock, you’re aware of the buzz that Salesforce DevOps is receiving.

Salesforce DevOps Center went Generally Available (GA) in December of 2022, driving focus through the roof for a new way of working.

Have you or your company decided to move past change sets and start using a DevOps process? Or are you researching a new solution?

I understand how difficult it is to navigate the different options on the market is difficult whether you decide on Salesforce DevOps Center, Copado, or Gearset.

So for this article, we’ll dive into the basics of Gearset to go from zero to hero in under an hour. Seeing a product in action and comparing it to others will help differentiate the options available.

What Is Gearset

Gearset was founded in 2017, focusing on making changes to Salesforce environments easier. They not only focus on DevOps but Data Backup and Seeding as well. Adding these services to allow for fail-safe environments within your pipeline.

Gearset themselves market as:

The only platform you need for unparalleled deployment success, continuous delivery, automated testing and backups.

The company has been around for a while and has excelled in making DevOps easy for all your team members.

Their focus on making the compare and deploy experience easy to navigate is top-notch.

Gearset differs from Salesforce DevOps Center in a few different ways. This comes from their time in the market and focuses on being a standalone application.

DevOps Center cannot compare your organization in a side-by-side metadata view. This is a fantastic feature available in Gearset. Since metadata is XML, it is hard to manage within source control. Gearset’s semantic engine makes comparing metadata a breeze.

You can also automate your pipelines and build backpropagated pipelines, keeping your orgs in sync. Gearset can run automated monitoring jobs on your environments, warning you in advance if you have testing or coverage issues.

Back Propagation is a lifesaver, with changes in a hotfix branch to production automatically triggering those PRs to merge into lower environments.

Due to being source control based, changes can be pushed through the UI and via source control, aka GitHub and terminal changes.

Gearset Pros

I love the dog food approach that Gearset follows. They release frequently, and you can always see what was pushed. Should we do the same within Salesforce? Letting our users know what has been released or changed so they can explore more?

The product allows you to get up and running fast. It just makes sense and is purpose built for agility and speed.

The support is top-notch. I don’t think I have ever had to wait for an answer for more than 5 minutes. Plus, if support doesn’t know something, they’ll contact the product team directly.

Gearset Cons

The product was originally designed for more individual workflows. As such, we don’t quite have the enterprise controls that we expect.

For instance, the pipelines are built around a single user. This has caused a few workarounds for us with our protected branches.

User provisioning is geared towards OAuth amongst Google and Salesforce. There’s currently no Single Sign On or SCIM provisioning.

Pipelines are still a new product for Gearset so there are a few bugs to work out.

That being said, Gearset is actively striving towards remedying all of the above and is responsive to user feedback.

Getting Started

Signing up for an account is easy. Gearset makes it relatively simple to signup for an account with your Salesforce account, LinkedIn, or Google.

As a UK based company, Gearset is focused on multiple data residencies

These are the same methods for authentication into your account – although I wish they had support for SAML and SCIM to allow for more enterprise user management.

Regardless of the method, you get free access through the trial for 30 days and receive no high-pressure sales cadences.

Getting Around

Once signed up, you’ll land on the homepage, a relatively streamlined experience with the ability to deploy changes front and center. I like this view because I can quickly start my deployment process. However, I sometimes wish it defaulted to my pipeline view, as I use it heavily.

Gearset homepage — Gearset provides an easy landing page to navigate

Across the side panel, it’s broken into functional areas:

Deployment (probably why you’re here).
Automation (CI/CD).
Data (excellent for seeding sandboxes).
Backup (pretty strong product).

For this article, we’ll focus on the Deployment and Automation sections.

If you’re looking for user management, it’s hidden under the Gearset logo under My Account. This placement is a little odd, but you get used to it.

Connect Salesforce Organization(s)

What is DevOps without having Sandbox instances to connect to?

On the left side, click Salesforce Orgs, which brings you to a listing of all the Salesforce instances you have set up.

It’s important to note that these only display your individual accounts, not the entire enterprise. This is one area I’m hoping will improve this year. I would like to know what instances are set up, especially if changes leave my company to a personal developer account.

Connecting a Salesforce org is easy. Click Add New Organization, and you’ll be presented with a modal asking what type of account you want to add and its username.

Your username here is essential. If you change it in the next step, authentication will fail.

You’ll be redirected to a Salesforce OAuth flow and accept the scopes.

Next, you can create a nickname for this org, so it’s easy to remember.

I turn on the monitoring for my production org and run unit tests. I also turn on unit tests for my staging environment, so I’m aware of any potential breaking changes well in advance.

We love the unit test monitoring as it has pointed out breaking changes in the past that may block future deployments.

Rinse and repeat for as many orgs as you need in your pipeline.

Connect Source Control

Next, we’ll add source control. This is where all your metadata lives and acts as a repository for changes. As part of our DevOps process, we’ll push changes to source control, and then our Salesforce orgs will look to that repo to determine what to change.

Click Source control and services where you’ll land on a page with all the potential version control platforms you can connect to.

Me, I use GitHub. Clicking on GitHub, I’m redirected through an OAuth workflow and am done.

Setup CI job(s)

Now we’re getting to the fun stuff! A CI job or Continuous Integration is where we tell Salesforce how to connect and listen to our source control repository.

We will use these CI Jobs as part of our pipeline later – you can create a CI job as part of the pipeline creation process. Still, for the sake of this post, we’ll keep them separate to highlight differences and if you still need to buy the pipelines feature.

To create a CI Job, we navigate to Continuous Integration and, for now, click on the grid or table icon.

Click Add new Deployment Job, which brings up a modal for a few crucial selections.

We have two approaches here. First, we choose the Source environment. If we need to build a source control-driven process, we can select a Salesforce org to act as the source. Since we are going with a source control process, for our example, we’ll choose Github as our source with the branch of UAT.

Next, we choose our target, which is our Salesforce org that we use for our UAT environment.

This does: for any changes that enter our UAT branch (through a Pull Request), sync these changes to our Salesforce UAT org. This starts a pattern of a branch per org pattern, allowing us to move changes in an automated fashion.

A few other necessary settings for calling out in the CI job.

One is the differences in deploying. If you’re just getting started and don’t want to make any significant destructive changes, leave off Deleted Items; you can always change this later.

Depending on your environment, you may leave running tests off on specific environments for speed of deployment. But I definitely recommend leaving running tests on in your staging environment. This ensures you don’t run into nasty surprises when you release to production.

Include User Permissions is something I would only enable if you’re comfortable with Salesforce metadata. Custom field permissions, permission sets, and profiles are some of the most detailed metadata to deploy. And, from personal experience, you can remove everyone’s FLS with one deployment, rendering your org useless. Best to leave this off as you’re getting used to DevOps.

Notification Settings

These are personal preferences. I leave these off in my lower environments and only turn them on for production or staging. I want to know if things fail and have a digest every time something changes in my org for visibility.

This helps with troubleshooting because we have an RSS feed in the form of a Slack channel called #salesforce-deployments.

If something bonkers comes up during the day, I can scroll through Slack and click on a deployment to see if something in the environment recently changed.

I won’t go into setting these settings, but you can click on each blue help bubble to learn more.

Metadata Filter

This is one area we whiffed about when setting up our jobs initially.

During a compare and deploy, you can choose what metadata you want to move between orgs and what you want to commit to source control.

However, there’s a secondary approach when deploying as part of a CI job: the metadata filter in the CI job itself.

Simply put, if you don’t select a metadata type here, your deployment will ignore it. I recommend choosing what is most common to your environment here. Setting more will slow down your jobs, and selecting less may leave out metadata when you release.

Once you’re comfortable with your settings, click save.

Congrats! You’ve set up your first CI job.

Rinse and repeat for the other environments you want as part of your DevOps process.

Build The Pipeline

We get a blank canvas if we click the pipeline button on the Continuous Integration tab.

This is where we draw our pipeline and set up individual components as part of the process.

For instance, reading from left to right, changes move from Integration to UAT to Staging to Production.

To start, we click on Add environment and then Add static environment.

Since we set up our CI Jobs in the last step, we will select Choose from an existing one. This will add the job to our canvas.

Here, I add my UAT and Production environments for this post. Still, you will have more in your experience.

From here, we click Edit environments to connect CI jobs, building our pipeline.

That’s it, we’re finished with the setup, and now we can push a change through. Easy, right?

Make a commit and Pull Request

I’m going to perform a bit of movie magic for the sake of this post, but let’s assume I’ve made a change in my developer sandbox or scratch org and want to push a change through to production using my newly created DevOps process.

To start, I click Compare and Deploy.

On my left, I choose my source org (my scratch org or dev sandbox); on the right, I select my source control, choosing to create a new branch off main.

Selecting main ensures we don’t push overwriting changes. This means we have a copy of what production looks like to compare against.

If you are working with someone on a feature or release, you may have to rebase off of another branch – which is outside the purview of this post.

When we click Compare Now, it will log in to both our source and target, comparing the metadata filters we selected.

On the next screen, we see what is new, what has changed, and what has been deleted. This allows us to select what we want to push through our pipeline.

Gearset does a great job of parsing our metadata, highlighting green vs. red for what has been deleted or added between the environments.

Here, I select my change and advance to the next screen.

This review section warns me about what I want to remove or include for a successful deployment. This is where knowing your changes and how Salesforce metadata works come into play.

These are best guesses, and sometimes you may need to override them based on your use case. Don’t worry. You’ll get the hang of this over time.

In the next screen, we can add our commit message and link to a Jira ticket if part of our process. I highly recommend a descriptive commit message so you have a running tally of changes and why. Better yet, use your ALM’s source linking features to ensure you have a running history of all changes in your org.

Gearset will push the commit to your remote branch.

From here, we’ll create our Pull Request to merge into our UAT branch, allowing us to kick off the process.

I like to include a description of what the PR does and the metadata in a list to make things easier during code reviews.

Once a PR is created, we see it staged in the pipeline. Gearset does some magic behind the scenes, creating a branch for each environment which does wonders for merge conflicts.

From here, we’ll merge into UAT, and the deployment process begins.

Our change is successful, and we now see a new PR for our main (production) branch. From here, we can merge our PR once again, and we’ve pushed our change straight through.

Easy enough, right?