Gearset’s continuous integration feature set has been evolving rapidly to better support mature application lifecycle management. This evolution has continued with our increased support for version control providers. Since we first added CI functionality to Gearset, with standard GitHub and Bitbucket version control included, we also now support GitLab, GitHub Enterprise, and more recently taken a huge leap forward to support any git-based source control repository to which Gearset has access.
With our latest release, we’ve now added the ability to pause a currently active CI job. Disabling a CI job may seem a little counter intuitive, but does make sense for certain scenarios. Firstly, you may not want a CI job to start deploying changes at the same time as hotfixes or ad-hoc changes to the same target org are taking place. To help prevent potential conflicts, the CI job can now be paused, the ad-hoc changes can be safely deployed to production and the CI job can be reactivated when safe to do so. Alternatively, you may want to simply set up the CI job in advance, but not have it run until other parts of the overall process have been completed.
How continuous integration in Gearset currently works
For anyone unfamiliar with Gearset’s CI functionality, it only takes a few moments to put in place, and begins with creating a new CI job.
Creating a CI job in Gearset:
- From the CI jobs tab, click Add new job.
- Give your CI job a meaningful name.
- Specify the source location of your metadata. This can either be a Salesforce org that you’ve connected to, or a version controlled repository.
- Specify the target Salesforce org where the changes will be deployed to. We’re planning to add support for version control as the target in a future release.
- Specify when the job will run. If the source is a Salesforce organization, the job will run automatically every four hours. If you’re using version control, you can also choose for the CI job to automatically run when the source branch is updated. This works via webhooks and only takes a few minutes to configure.
Note: our CI feature also enables you to include only specific metadata types, as well as the nature of the changes to be deployed (e.g. new, changed and/or deleted items). You can also choose to ignore any existing package.xml file that exists in the repo.
Temporarily disabling CI jobs in Gearset
Gearset displays all current CI jobs from the jobs overview page. This enables a quick and easy way to look back at changes deployed for each CI job run, whether triggered every four hours or when a branch was updated.
From the currently created jobs, we’ve now added an additional action that lets you simply toggle the current status for any CI job that you are the owner of (i.e. you created the job). You can choose to disable the job at any time, and then re-enable the CI job again when ready.
Note: you cannot disable a CI job for which you are not the owner. If you’re part of a team in Gearset, you will need to contact the person who originally created the CI job and ask them to disable it.
Try Gearset now
We really hope you find the addition useful - if we’re missing something that you’d like to see, then just pop a suggestion on our feedback forum, or fire us an email!