Continuous Integration (CI) is a software development best practice of automating your test suite, so all your integration and unit tests run on every merge or pull request automatically. This way you know before you merge if problems are going to be introduced. You use a CI tool with a Version Control System (VCS) and it is best practice to require a review via pull request and enforce passing tests before the pull request can be merged. Early fixes save your company money and keep your team and users happy.

How does CI work in practice?

Continuous Integration is conducted by a CI tool that talks to your version control system. You and your team set up your CI tool of choice in your repository and set rules around when your test suite needs to run. Once these rules are in place, whenever you take an action that triggers the tests, the CI tool runs a script in the background that configures your environment, deploys the changes, and runs the test suite. Upon completion, the tool provides a log and details on which tests passed and when and where the test build failed. You can set up your pull request rules so that changes can not be merged till all builds pass. This way you know you aren’t introducing any new bugs into your code whenever anyone on your team proposes changes.

It is a best practice to perform testing in a test environment, such as a sandbox or scratch org. When using automation, it is preferable to create a disposable environment (like a scratch org) to test specific code/changes instead of introducing these changes to a shared org. Salesforce CLI allows you to automate the creation of scratch orgs as part of your CI process. What’s also really cool is that Salesforce CLI enables you to completely script all these tasks in the CI configuration file whether you are using org-based or package-based development.

Count me in! So how do I set it up?

Glad you asked! We’re here to help. For those of you who haven’t implemented CI before or don’t have experience with a specific vendor, we created the Trailhead module Continuous Integration Using Salesforce DX and a set of example repositories for some of the most popular CI vendors out there. Each vendor we currently cover has two repositories: One is based on the package development model, for teams using scratch orgs and unlocked packages to deploy their changes. Another is based on the org development model, for teams that use sandboxes and Metadata API commands to deploy their changes to production.

Each repository has a readme that walks you through the steps of setting up the CI vendor’s tool with the SFDX project and your version control system. It also includes a sample CI configuration file that gets you started with CI. To use these repositories, fork one, and then make a few updates to the configuration file with your authentication details.

We currently have repositories for the following vendors:

We choose these tools based on what most customers are currently using. If you’d like to see a public repository for another CI vendor, let us know by commenting on the Salesforce DX Trailblazer Community.

OK, but there are so many vendors. How do I choose?

Choosing the right vendor depends on your team’s requirements. Luckily, you can use any CI tool with the Lightning Platform. When choosing a CI tool, here are some things you should consider:

Do you want to run your tests in the cloud or on your own server?
Your company may need an on-premise solution if they need access to private network resources, or need to find a CI service that supports VPN. Does your company have the IT resources and skillset to manage and run the CI servers? If not, a cloud-hosted option is likely better.

What VCS tool do you use? Do they have an integrated CI tool?
If you are using Bitbucket or GitLab, they both have their own integrated CI tool built in, which means set up can be easier. Bitbucket and GitLab also work with the other CI tools as well.

What operating systems do you want to test on?
Salesforce CLI is supported on Mac OS, Windows, and Linux—Ubuntu. Your team should think about the kinds of scripts and commands you want to execute and are familiar with.

What does the pricing look like?
The pricing varies by vendor, and most charge by Docker image. Bitbucket charges for minutes used, which can be cheaper if you are running fewer tests per build. CircleCI has a free business plan, which can be a good choice if you are getting started with CI. Think about how many tests you’ll run per build and how often and compare prices. Another consideration is public vs. private version control repositories. Some vendors offer free hosting and CI resources for open source projects.

Each vendor is different and what they offer and how they price changes over time, so do your research. In the end, it is up to your team to pick the tool that suits the way your team works best.

Start checking out the new open source CI repositories and let us know what you think. Learn more about how to develop using Salesforce modern tooling in the Getting Started with Salesforce DX blog series. If you are already using Lightning Web Components, check out the LWC Recipes for CircleCI.

About the author

Claire Bianchi is the Product Manager for the Salesforce CLI. She joined Salesforce in June 2018. Prior to this role, she was at Atlassian as the Product Manager of the Bitbucket Ecosystem and Front End teams. She holds two degrees from the University of California, Berkeley: a BA in Economics and an MBA from the Haas School of Business. Prior to grad school, she was in database marketing at Hotwire.com and ran CRM at UniversityNow. Follow Claire on Trailhead, LinkedIn, and Twitter @ClaireSFDX.