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

When you create a CI 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 across. A deployment report is saved in your history, along with the package created, and we'll notify you using your configured options.

Gearset CI fully supports both Salesforce orgs and version control systems.

Setting up a CI 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 the Connections page, found under Manage connections in the nav menu on the left.

  • Navigate to the CI jobs page, found under Automated jobs
  • Click on Add new job
  • Give the job a descriptive name (e.g. GitHub to Staging)
  • Select the source connection type (an 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 what items are deployed
  • Select the target connection type (an 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 an org as the source, this will be every 4 or 24 hours. If you're using version control as the source, you can also choose to run the job when the source branch is updated
  • Set if you would like the job to include New objects, Modified Objects, and Deleted objects
  • 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 (see section below for more info)
  • 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.

For a CI job to run when the source branch is updated, Gearset will provide you with a payload URL and shared secret when you save the CI job.

You need to copy over the payload URL and the shared secret shown, and save the new webhook in your source control provider (such as GitHub, pictured below).

Note: the content type for your webhook needs to be in the JSON format. You can set the format when configuring your webhook in your source control system.

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 when the CI job fails
  • Enter the email addresses of who to notify of the result
  • Gearset also supports SMS notifications (UK and US only), Slack & Microsoft Teams integration via webhooks and Chatter integration

Validation-only CI jobs

Within Gearset, you can also set up validation-only CI jobs between any of your Salesforce orgs, 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 CI jobs page, which can be found under Automated jobs in the left-hand side menu. To create a new job, select the validation only option in the dropdown menu next to the Add new job button and follow the same work process as before.

Managing and viewing your CI jobs

The CI jobs overview displays all your current CI jobs, a summary of the source and target, when the job was last run and its outcome. You can also manually start a CI job on-demand if required 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 deployment report, package deployed, and the CSV summary, just like any other deployment in the app.

For CI jobs when the deployment was unsuccessful, 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 via your webhook.

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, 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 code analysis every time a CI job runs. To find your static code analysis results, navigate to the CI Jobs page and click View history to see the results of one of your CI jobs. Click View code analysis… for any of the job runs to see the full rundown of the changing state of your Apex code.

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.

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 above the job history table.

Did this answer your question?