Gearset has full support for end-to-end continuous integration and continuous delivery without the need for external software such as Jenkins. 

Gearset CI can be set up with both Salesforce orgs and version control systems (source control).

When you create a CI deployment job, Gearset will automatically compare your environments, select the metadata you specify and analyze it to find any dependencies through our advanced problem analyzers. It then builds the deployment package, runs your tests, and deploys the changes. A deployment report is saved in your history, along with the package created, and we'll notify you using your configured options.

You can also create a validation-only CI job (sometimes referred to as continuous validation).  This would be recommended if the target is a production org.

Setting up a CI deployment job in Gearset

Before creating a CI job, you first need to have added some connections to your orgs or source control repositories. You can do this via My connections in the nav menu on the left.

  • Navigate to the Continuous integration page, found under Automation in the nav menu on the left.
  • Click on ADD NEW JOB....
  • Give the job a descriptive name (e.g. 'GitHub to Staging').
  • Select the source connection type (a Salesforce org or a version control system).
  • If you selected a version control system, select the branch to use and choose whether Gearset should use a package.xml file to control which items are deployed.
  • Select the target connection type (a Salesforce org or a version control system).
  • If you selected a version control system, select the branch to use.
  • Choose how often you want the job to run. If you're using a Salesforce org as the source, this can be every 4 or 24 hours. If you're using version control as the source, you can alternatively choose to run the job when the source branch is updated.
  • If you choose the latter option, your target is a Salesforce org, and your source is a GitHub, GitHub Enterprise, Bitbucket or GitLab branch, a new box will appear, giving you the option to validate pull requests targeting the source branch.
  • Select if you would like the job to include New items, Changed items, and Deleted items.
  • Decide if you want to include changes to user permissions in your CI job; by default these are excluded.
  • On the Notification settings tab, choose if you want to be notified when the job runs, or only if the CI job fails. (See later in this article for further details on notification preferences.)
  • On the Metadata filter tab, set the metadata filter you'd like the job to use. This defines which metadata types the CI job will compare and deploy between your two orgs. (See more on custom metadata filters.)
  • Click Save to create the job.

Setting up a webhook for a CI job from source control

When deploying from a source control repository to a Salesforce org, you can configure the CI job to run when the source branch is updated via a webhook. 

Webhooks allow Gearset to detect changes pushed to a repository in real time, without having to poll to see if anything has changed. Whenever you push to the repository you've set up, Gearset will immediately pick those changes up and sync them to your target.

When creating a CI job to run when the source branch is updated, after you press Save, a screen like the image below will appear, with instructions and a Payload URL and Shared secret.

As per the instructions in the box above, you need to set up the webhook in your source control system, pasting in the payload URL and the shared secret, and setting the content type to be the JSON format. (GitHub webhook setup pictured below.) 

Making sure that the push setting is selected (Bitbucket webhook setup pictured below.)

Validate pull requests

For a CI job from a GitHub, GitHub Enterprise, Bitbucket or GitLab branch to a Salesforce org, which you've selected to run when the source branch is updated, you also have the option to validate pull requests targeting the source branch (e.g. master). When this box is ticked and you follow the instructions to set up the webhook, this will automatically create a validation-only CI job when a pull request is created.

The process to set up the webhook is very similar to that described above, but this time you need to select pull requests to be a trigger in addition to pushes. Simply follow the instructions that appear on your screen after you have created the CI job in Gearset.

Once this is set up, when you create a pull request (PR) to merge into your specified source branch, we'll receive the webhook from your version control system, and match it up with the CI job. We'll then create a new validation-only child CI job using a copy of the parent job’s settings, except with the PR branch as the source. This will be shown in the Continuous integration dashboard - click on the parent job and the child job will be shown below it.

We'll post the status to your version control system so it shows up on the PR - example screenshot from GitHub below. If all checks have passed, you can merge the PR, triggering the CI deployment job, confident that the deployment to the org will be successful, as the Salesforce validation succeeded.  If the validation fails, you know to not merge.

When the PR is merged or closed, we’ll delete the child job from the Continuous integration dashboard.

Setting your notification preferences for CI jobs

  • Select the Notification settings tab.
  • Choose whether to get notified after every CI job run, irrespective of the outcome, or only if the CI job fails.
  • Enter the email address(es) of who to notify of the result.
  • Gearset also supports SMS notifications (US, UK and Australia only), Slack and Microsoft Teams integration via webhooks, and Chatter integration.

Validation-only CI jobs

Within Gearset, you can also set up validation-only CI jobs, so you can catch any problematic changes early and make sure that when the time comes to deploy, you’ll be able to release successfully.

To set up a validation-only job, navigate to the Continuous integration page, which can be found under Automation in the left-hand side menu. To create a new job, select the Add validation only CI job option in the drop-down menu next to the ADD NEW JOB... button and follow the same work process as with standard CI deployment jobs.

Managing and viewing your CI jobs

The Continuous integration dashboard displays all your current CI jobs, the source and target for each, when the job was last run and its outcome. When you click on a job, the Job type will be displayed: either Deployment or Validation. For jobs you own, you can manually start a CI job on-demand by clicking on the play button in the actions column. To see the details of every time the CI job ran, click on View history.

For successful CI job runs, you'll be able to download the PDF deployment report, package deployed, and the CSV summary, just like any other deployment in the app.

For CI jobs when the deployment failed, clicking the view errors button will show you the full list of deployment errors. These can be exported as a CSV file for easy reference and debugging.

Temporarily disabling CI jobs

When a CI job is created, it is added in an Enabled state. This means it will automatically run using the trigger you specified - either every 4 hours, every 24 hours, or when the source branch is updated.

You can stop CI jobs from running automatically by switching their status to Disabled. A disabled job will not run unless you click the Run now button (only available if you are the job owner), regardless of any webhooks or timing options set during creation. To switch a job between enabled or disabled, click the slider into the desired state.

Viewing the static code analysis results of your CI jobs

As well as running during manual deployments and in change monitoring jobs, Gearset’s fully configurable static code analysis now also automatically runs as part of your CI jobs. If you want to find out how to configure your rule set see our help guide.

Gearset will automatically perform your static code analysis every time a CI job runs. To find your static code analysis results, navigate to the Continuous integration page and click View history to see the results of one of your CI jobs. Click View static code analysis issues for any of the job runs to see the code analysis issues for that run.

When you view your code analysis results for each job run, Gearset will display any detected rule violations and group them within the class that they belong to. You can click the menu on the left to view specific violation categories or use the text filter to narrow your results down to a specific class.

For any violation detected, Gearset will tell you which line of code the issue begins on and provide a description of the violation, so you can easily understand why issues have been flagged. For more detailed information on each specific rule, click the name of the rule and you’ll be taken to the PMD library for a more in-depth look at the individual rule and its implementation.

Problem analyzers and your CI jobs

As well as running static code analysis, Gearset will apply problem analyzers to all CI jobs. You can read more on how problem analysers affect your CI jobs here.

Filtering CI job history by date

By default, the CI job history will display jobs runs created in the last 10 days. You can change this filter view by clicking on the date range drop-down menu.

Did this answer your question?