Plenty of teams building on Salesforce would like to add automation to their release process, building out a CI/CD pipeline. But this ambition raises key questions. How does CI/CD actually work for Salesforce? How do I know when my team is ready for release automation? And why do so many teams struggle to make a success of it?
We’ll address all those questions in this article. For a broader overview of CI/CD for Salesforce, you might want to download our free ebook on the topic:
Understanding CI/CD terminology
Let’s start with some definitions. Development teams can mean different things when they talk about “CI/CD”, so it’s worth unpacking some definitions of the relevant terms and concepts that tend to get bundled together.
Continuous integration
Continuous integration, the “CI” part of CI/CD, is the practice of merging development work in your version control system (VCS) early and often. This practice confirms that your work can be successfully integrated with the rest of your code — including the work that your teammates are also merging frequently. The longer you hang on to development work in a Salesforce org or feature branch, the more likely you’ll hit a conflict when you try merging.
Continuous delivery
Continuous delivery, the CD part of CI/CD, is the overarching aim to deliver to end users more frequently, which can be achieved by automating the flow of work through your release pipeline.
Continuous development
Some people use the term “continuous development” to mean much the same thing as “continuous delivery”. These are both umbrella terms for the whole automation process, encapsulating everything from continuous integration to continuous testing. The terms can be used interchangeably, but we prefer “continuous delivery” because it’s more focused on the value of CI/CD to end users.
Continuous deployment
Sometimes “CD” is used to mean continuous deployment instead of continuous delivery. Continuous deployment means automating the final release to production, so everything that passes your automated tests is also released automatically. This approach requires complete confidence in your tests and testing processes.
What are the benefits of Salesforce continuous integration?
The practice of continuous integration is central to some important aims for any DevOps process: shipping smaller changes more often, and always being able to release on demand. In fact, continuous integration is the key that unlocks most of the benefits people associate with DevOps:
- Faster delivery. CI encourages developers to merge work as soon as there’s something of value to release to end users.
- Tighter feedback loops. Regular releases also mean end users can give feedback earlier and shape the direction of development.
- Better collaboration. Integrating workstreams continuously also fosters collaboration between developers and different development teams.
- Fewer bugs. CI means teams can “shift left” their automated testing and checks, catching issues and errors early on, when they’re easiest to fix.
- Higher productivity. All of the above leads to higher productivity across the development team, substantial time-savings, and reduced lead times for projects.
- Shorter recovery times. When a release causes issues in production, it’s easier to roll back and debug a smaller release — or even roll forward and ship a fix in the next release.
- Ever-increasing release reliability. Releasing much more often means the whole process quickly gets battle-tested.
When it comes to achieving the benefits of DevOps, teams following CI/CD best practices outperform everyone else, according to data from our State of Salesforce DevOps survey.
Is my team ready to adopt Salesforce CI/CD?
To get all the benefits of CI/CD, you need to build on strong foundations, so it’s critical to make sure your team is at a sufficient level of DevOps maturity before you begin. There are a couple of questions you should ask when assessing this:
- Are our deployments repeatable and reliable?
- Are we already using version control as the source of truth in our development process?
Any attempt to implement CI/CD before you can answer “yes!” to both of those questions will fail, and the experience might dent your team’s willingness to embrace future attempts to improve your CI process.
Only repeatable, reliable processes can be successfully automated, so until your team has a solution to the problem of Salesforce deployments, which are notoriously error-prone, implementing a CI/CD pipeline will be premature.
What makes continuous integration for Salesforce difficult?
No-code team members face a technical learning curve
Declarative developers used to deploying change sets on Salesforce have a whole bunch of concepts and practices to learn about version control, CI/CD and DevOps in general. But to be successful, CI/CD needs the backing of the whole team, so educating admins and developers is vital for success.
DevOps Launchpad is a free training platform where you can start collecting certificates on all things Salesforce DevOps right now — whatever your role.
Generic pipeline tools don’t solve the fundamental challenge
Setting up a CI/CD pipeline using cross-platform automation software takes time, effort and technical expertise. But the real issue is that these tools don’t address the quirks of Salesforce deployments. As a result, many teams spend their time wrestling with open-source toolchains that take more effort to maintain than they save on deployments. A brittle CI/CD pipeline doesn’t help to achieve continuous delivery.
Using Gearset, you’ll see CI/CD success because it’s built specifically to handle Salesforce metadata and make sure deployments work first time. Gearset’s deployment engine has built-in “problem analyzers” that find and fix common errors in deployment packages.
CI/CD has to involve a cultural shift
Getting hold of automation tools is easy. Setting up a CI/CD pipeline doesn’t have to be difficult either. But CI/CD is first and foremost a way of working, and bringing about cultural change can be the biggest challenge. Every team member needs to be persuaded that continuous integration is worthwhile, until it’s ingrained in the team’s mindset.
What does Salesforce CI/CD look like in Gearset?
Continuous integration tooling is one part of Gearset’s Salesforce DevOps platform. Within the CI dashboard, there are two main options:
- Standalone CI jobs. You can set up individual CI jobs that automate deployments and/or validations between two environments. These CI jobs give you ultimate flexibility to build any kind of release process, around any Git branching strategy.
- Pipelines. In essence, Pipelines, our Salesforce CI/CD solution, allows you to string together a series of CI jobs, then visualize and manage the whole CI/CD pipeline in one place. It’s an incredibly powerful option for teams that need a slightly more sophisticated branching strategy with multiple persistent branches. It’s also packed with added automation, from automatically created pull requests to automatically resolved merge conflicts.
Find out how you can create a CI/CD pipeline for Salesforce in this article on Gearset Pipelines. Below, we’ll walk through the process of setting up an individual CI job in Gearset, to introduce the possibilities for release automation.
Setting up a CI job in Gearset
If you’d like to follow along with this walkthrough, you can start a free trial of Gearset and create your own CI job. There’s nothing to install anywhere — you simply log in using Salesforce, Google or LinkedIn credentials.
1. Select the source and target environments
Once you’ve logged into Gearset, head to the Continuous integration page via the menu on the left.
Click on the Add new deployment job button in the top right. You’ll now be guided through the process step by step, and we’ll pick out the key details as we go.
The first step is to select the source and target environments for the job. In the example shown below, we’ve selected the main branch of our Git repository as the source, and our UAT org as the target. Gearset supports all the major Git hosting providers.
2. Choose the kind of automation
Next, you can decide whether this CI job will deploy changes or only validate them against the target. You can set the job to deploy the delta — only the changes you’ve made — or to sync up any differences between the source and target. You can also decide which combination of new, changed, and deleted items should be deployed.
We’ve set our example CI job to run whenever changes are merged into our main branch, but you can have your job run on a set schedule if you prefer. We’re also validating all pull requests against our UAT org, so we can be sure changes are deployable before merging pull requests into main.
The following page also allows you to specify which tests you want to run.
3. Filter by metadata type
Most teams will be interested in a specific set of metadata types that need to be deployed. Gearset’s metadata filter gives you fine-grained control over which types should be fetched and deployed via Salesforce’s Metadata API.
4. Apply quality gates and fixes
Gearset lets you build static code analysis rulesets and apply them to your CI jobs. You can decide whether or not code errors or warnings should block a deployment. And you can also select which of Gearset’s problem analyzers should be applied automatically to your deployments.
If you want a CI job to trigger an external service, that’s supported by the outgoing webhook option. Otherwise, it’s just a case of setting up any notifications you want to receive, and your CI job is complete!
Next steps
By starting a free 30-day trial of Gearset, you get full access to the platform, including all its continuous integration features. It’s a quick and easy way to see what’s possible for Salesforce CI/CD.
If you’re still wanting to learn more, you can always set up some time with our DevOps experts to discuss your exact requirements and arrange a tailored demo. And our CI/CD for Salesforce ebook is a great resource to share with your team.
