All Collections
Feature guides
Version control
Enforcing code review before promotion
Enforcing code review before promotion

If you're using Gearset Pipelines you may want to enforce code review, making sure that all pull requests tested and approved

Claudia McPhail avatar
Written by Claudia McPhail
Updated over a week ago

Gearset's quality control

By default all pull requests which are validated by Gearset go through a minimum level of automatic testing, which is Salesforce validation. Any change that you are attempting to introduce into your Pipeline will need to be validated against the org you'd like to deploy it to, to make sure it's functional.

You can add extra layers to this integrated testing, in the settings of the CI jobs that make up your pipeline.

Unit testing

Configure the level of unit testing you would like to run on the code that you've included in your pull request, and the org that you're deploying it to. we have more information on what these testing levels mean here.

If the pull request does not pass the specified level of testing then it remains as a pull request and cannot be merged until these issues are resolved.

Try the 'run only the changes in my package' if you'd like to run tests only on any new code you're introducing rather than any legacy code that may be in your org and slow you down.

Static code analysis

Gearset supports the creation of customized static code analysis rulesets (learn how to create one here ) and you can use these to make sure that if specific rules are violated then the promotion of a pull request will be blocked. Gearset will run static code analysis over the proposed change and produce a report on the code quality of the pull request. If the code quality violates the rules configured in that CI jobs settings then the change cannot be promoted.

Try monitoring jobs if you'd like to see the static code analysis report of an entire org at once.

Lightning web component testing

This is a piece of integrated testing which can only be found in the Pipelines and CI part of Gearset, and allows you to integrate the testing of your LWC into your Pipeline. Depending on the settings you configure you can prevent a pull request being promoted if the lightning web components within that pull request do not pass their tests.

Code review

There are many ways to incorporate code review into your Gearset Pipeline - you might want to integrate Jira and your internal comms channel and tag a teammate in a ticket update. You might also want to follow the more traditional path and do your code review on the pull request itself.

This is where we see one of the advantages of connecting Gearset with your businesses chosen source control provider. If the business already has a minimum standard of code review or protected branches then Gearset will respect that.

You may want to set up some new rules for your Pipeline to make sure that your teammates are viewing and approving any changes that you're making. Depending on your source control provider these may be called branch rules or branch policies.

Azure DevOps

In Azure these are called branch policies.

  1. View your branches.

  2. Hover over the branch you would like to apply the policy to, and click the 3 dots on the far right hand side.

  3. Open "Branch policies"

  4. Decide on your chosen policy. A popular choice is to choose a required number of reviewers and set the number to 1.

The promotion of the change will now be blocked until at least one other person has approved it.

Github

In Github these are called branch protection rules.

  1. Go into your repository settings.

  2. View Branches.

  3. Click Add rule and make sure the name of the rule is the same as the branch you want to protect.

  4. Decide on your chosen policy.

The promotion of the change will now be blocked until at least one other person has approved it.

With these settings checked, the Promote Changes button will still show against your PR's in the Pipeline, but will not let them be merged and show this message if the Review has not been completed

If you are a Repo Admin; to see the same behaviour in Pipelines, make sure the following setting is checked

GitLab

In GitLab you can protect branches, which means that only limited groups are able to directly push code.

  1. Got into your repository settings.

  2. Find the Protected branches section and choose the branch you want to protect.

Merge requests are required before being able to push code to this branch.

Bitbucket

In Bitbucket you can set up Branch permissions.

  1. Go into your repository settings

  2. Click Branch permissions, and Add a branch permission

  3. Set permissions for specific users, and certain requirements that have to be met before a branch can be merged.

Now no one except Claudia McPhail has write access to that branch, and all pull requests require at least one review before they can be merged.

Did this answer your question?