Contact sales: +1 (833) 441 7687

How to set up automatic validations of pull requests for orgs in a CI workflow

Jess Wilkinson on October 7th 2019


At Gearset, we’re always listening to our users. From feature requests to pain points, your feedback shapes what we build. Recently, we heard from Salesforce teams using the feature branch model about some changes we could make to improve the way Gearset handles CI jobs across multiple feature branches. In light of this feedback, we’ve added automatic pull request validations to Gearset’s continuous integration feature.

Continuous integration, version control and validations

If you’re one of the many Salesforce teams adopting DevOps to help manage the release and maintenance of changes to your orgs, then you’ll be no stranger to version control and continuous integration. Under these models, developers create feature branches from master (or another integration branch) to work on new features. These branches keep track of all of a feature’s changes and, when complete, they’re merged back into master. From master, the feature can be deployed out to any number of environments, following a clearly-defined and largely automated release process. A typical Git workflow looks like this:

And you’ll no doubt be reaping all of the benefits those models afford - fewer merge conflicts, and more regular and reliable releases.

However, there’s one major shortcoming of these models when they’re applied to Salesforce. Because an org is essentially both the compiler and the runtime for the Salesforce platform, the only time you test whether your changes build and run properly is at the point they’re deployed to an org. In an org-based develop model, this isn’t such a big problem. You build your changes in one org, then deploy them out to another when you’re happy, and if you’ve missed a dependency or you attempt to deploy something undeployable, then you’ll get a failure message then and there. When you introduce Git to this workflow, your changes get merged to master when you’re happy with them, but they’re only tested for deployability at the point that branch gets deployed to an org.

Using continuous integration to monitor your master branch and deploy any changes to a staging environment goes some way towards mitigating this problem. When a feature branch is merged into master, your CI tool will detect the change to the branch, package up your changes and push them out to your staging org. At this point you’ll receive a failure notification if you’ve merged breaking changes. This helps somewhat - you find out about the breaking changes in a timely manner, at which point you can fix them. This still isn't ideal though, as it means you’ve got a master branch that’s broken and undeployable until those changes are fixed, which can disrupt the rest of your team. It can also cause an undue amount of stress until the branch is fixed. Wouldn’t it be better if you could have confidence that your changes were complete and deployable before merging them into master?

Many DevOps teams use Gearset’s CI to monitor a git branch and deploy changes to an org when a commit is detected - but this alone doesn’t resolve the situation entirely. These teams often set up validate-only CI jobs, to check that changes within feature branches will be deployable before they get merged into master. Unfortunately, until now, this has meant manually creating a validate-only CI job per feature branch, which is time-consuming. In the latest release, we’ve made some changes to Gearset that remove these manual steps.

Run automatic validation tests of your PRs faster with Gearset

Validations in Gearset already simulate your deployments in advance, without actually pushing your changes to your orgs. Like a regular deployment, Gearset updates the metadata and runs any tests behind the scenes during a validation - but it won’t modify your org in any way. This way, you can catch potential issues with your deployments before they make it to your environments and break anything. This ability to continuously check if changes are good means your team can work on changes throughout the week, running validations to be confident that their work will deploy as expected. You can then schedule deployments containing only good changes outside of working hours, minimizing the risk of a deployment failure and disruption to others working in that environment.

If you’re using a Git-based workflow, automatic validations of PRs bring this functionality to an even earlier point in your deployment process. As you commit PRs from feature branches to your environments, Gearset simulates how your changes will deploy further down the line. This gives your team more time to make fixes and avoid merging or building on bad changes altogether.

Gearset users are already enjoying the time-saving benefits of including automatic validation of PRs in their deployment process:

'This will save literally hours of unplanned work. We are loving this new feature. It has already caught two pull requests that would have made it through review and clogged up our deploy chain.' - Jim Young, Manager, Ops & Intel at ETE Reman

Automating this process means Gearset can warn you, at the earliest possible stage, if your changes are likely to break anything when merged to master. Simulating the deployment of your changes to master, at the time that they're committed, gives you an early warning of any breaking changes, and the opportunity to make fixes before merging.

How to set up automatic validation of pull requests

When creating a new validate-only CI job in Gearset, simply check the Validate pull requests targeting the source branch box in the Add CI deployment job window that appears when setting up the job:

When setting up the webhook on GitHub, check the Pull request webhook event:

Once this is enabled for a job, Gearset displays any pull request validations right underneath the associated CI job in the CI jobs overview panel. You can see at a glance which jobs have pull requests associated with them:

If your pull request fails validation, including any tests associated with the parent job, GitHub displays a failure message. You can then correct any issues in your branch prior to merging.

This feature also supports Bitbucket and GitLab - so if you're using one of those platforms, you can still benefit from automatic validations of your PRs.

If your PR passes, GitHub displays a success message on your commit:

Any ideas on how we can keep improving?

If this feature has helped you, or if there’s a new feature you’d like to see in Gearset - we want to hear from you! Get in touch with the team via the in-app chat or at [email protected] for a free trial of the Enterprise tier. Alternatively, you can leave us a feature request on our feedback forum.

Ready to get started with Gearset?

Start free trial