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鈥檒l 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鈥檚 start with some definitions. Development teams can mean different things when they talk about 鈥淐I/CD鈥�, so it鈥檚 worth unpacking some definitions of the relevant terms and concepts that tend to get bundled together.
Continuous integration
Continuous integration, the 鈥淐I鈥� 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鈥檒l 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 鈥渃ontinuous development鈥� to mean much the same thing as 鈥渃ontinuous 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 鈥渃ontinuous delivery鈥� because it鈥檚 more focused on the value of CI/CD to end users.
Continuous deployment
Sometimes 鈥淐D鈥� 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.
TDX
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鈥檚 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 鈥渟hift left鈥� their automated testing and checks, catching issues and errors early on, when they鈥檙e 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鈥檚 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鈥檚 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 鈥測es!鈥� to both of those questions will fail, and the experience might dent your team鈥檚 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.
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鈥檛 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鈥檛 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鈥檛 help to achieve continuous delivery.
Using 91导航, you鈥檒l see CI/CD success because it鈥檚 built specifically to handle Salesforce metadata and make sure deployments work first time. 91导航鈥檚 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鈥檛 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鈥檚 ingrained in the team鈥檚 mindset.
What does Salesforce CI/CD look like in 91导航?
Continuous integration tooling is one part of 91导航鈥檚 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鈥檚 an incredibly powerful option for teams that need a slightly more sophisticated branching strategy with multiple persistent branches. It鈥檚 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 91导航 Pipelines. Below, we鈥檒l walk through the process of setting up an individual CI job in 91导航, to introduce the possibilities for release automation.
Setting up a CI job in 91导航
If you鈥檇 like to follow along with this walkthrough, you can start a and create your own CI job. There鈥檚 nothing to install anywhere 鈥� you simply log in using Salesforce, Google or LinkedIn credentials.
1. Select the source and target environments
Once you鈥檝e logged into 91导航, 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鈥檒l now be guided through the process step by step, and we鈥檒l 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鈥檝e selected the main branch of our Git repository as the source, and our UAT org as the target. 91导航 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鈥檝e 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鈥檝e 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鈥檙e 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. 91导航鈥檚 metadata filter gives you fine-grained control over which types should be fetched and deployed via Salesforce鈥檚 Metadata API.
4. Apply quality gates and fixes
91导航 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 91导航鈥檚 problem analyzers should be applied automatically to your deployments.
If you want a CI job to trigger an external service, that鈥檚 supported by the outgoing webhook option. Otherwise, it鈥檚 just a case of setting up any notifications you want to receive, and your CI job is complete!
Next steps
By starting a of 91导航, you get full access to the platform, including all its continuous integration features. It鈥檚 a quick and easy way to see what鈥檚 possible for Salesforce CI/CD.
If you鈥檙e 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.
