Salesforce CI/CD best practices

All Salesforce teams want to have a fast-flowing release pipeline. But working out how to build or optimize an automated CI/CD process isn’t always easy. For some teams, DevOps concepts and practices are relatively new and unfamiliar. For other teams, it’s Salesforce that poses a challenge because it just doesn’t behave like other platforms where CI/CD can be achieved with standard automation tools.

CI/CD aims and DevOps culture

In this article, we’ll cover a number of best practices for Salesforce CI/CD. But there are a couple of themes that run through all of them, and it’s worth pointing those out before we dive in.

Firstly, the aims of CI/CD determine best practice. While there are specific decisions to make about Salesforce, the aims of CI/CD remain the same as for any platform:

• Integrate workstreams at the earliest opportunity
• Catch and resolve issues early in the release cycle
• Improve transparency and collaboration within teams
• Automate the pipeline and reduce friction
• Release smaller deployment packages more frequently
• Tighten the feedback loop to encourage user-driven development

Secondly, the importance of culture can’t be overstated. Most of these best practices need the right tools and processes in place, but none of them are possible without the team forming attitudes and habits that shape their behavior.

While all of these best practices are interrelated, we’ve grouped them under three headings: environment management, continuous delivery, and security. And since there are plenty of points to consider, we’ve added a handy CI/CD checklist at the end of this post.

Environment management: keep on top of Salesforce and Git

A fundamental decision for Salesforce CI/CD is which environments to include in your release pipeline. You need to decide which orgs are used where, and what Git branching strategy to adopt — while also thinking about a strategy for managing all of those environments long term.

Create a sandbox strategy that supports your CI/CD process

There are, of course, many different kinds of Salesforce org, from developer orgs through to full sandboxes. And teams may think of their purpose slightly differently:

• Integration orgs where different contributors’ changes are merged together
• Quality Assurance (QA) orgs where testers can verify work functions as expected
• User Acceptance Testing (UAT) orgs where end users can validate that features and customizations meet their needs
• Staging orgs for final checks before a release to production
• Hotfix orgs for making urgent changes with an expedited route to release

Each business has its own requirements that will guide decision making on which orgs are needed for what purpose. We’ve worked with thousands of Salesforce teams and seen pretty much every variation imaginable for how orgs can be used.

That said, it’s important that your choice of Salesforce environments helps to achieve the aims of CI/CD. Since CI/CD should accelerate the release cycle, it’s always worth keeping the number of environments you have to a minimum — each environment represents a stage in the process that takes more time to manage. And it’s worth investing in a full sandbox for a UAT or Staging org, so that it matches production as closely as possible.

The burden of sandbox management can be reduced by using scratch orgs. Whether it’s developing discrete features or spinning up a clean testing environment, if your team has any use cases that are well suited for scratch orgs, it’s worth adopting them and having fewer permanent orgs that need ongoing maintenance. Gearset supports the automatic creation of scratch orgs as part of a continuous integration job.

Choose a Git branching strategy that matches your aims

There’s no one Git branching strategy that works for every team, and we’ve seen teams adopt a wide range of options. Broadly speaking, there’s a balance to strike between velocity and resilience. But the other guiding principle is that your Git branching strategy should support your sandbox setup. For example, teams often have permanent Git branches that correspond with their Salesforce orgs.

There’s no “right” answer to which Git hosting provider and Git branching strategy you should choose — but there are wrong answers. If your approach to version control feels like it’s in tension with your process, then it’s time for a rethink.

There are plenty of version control best practices that are worth following:

• Use a consistent naming convention for feature branches.
• Commit small, logical units of work regularly.
• Annotate commits for easier collaboration and auditing.
• Keep all the changes for a feature in a single feature branch.
• Write clear pull request notes (PR templates are a real help).
• Create a robust peer review process for pull requests.
• Put branch protection policies in place to prevent mistakes.
• Keep feature branches short-lived.
• Delete branches after merging.

Keep your environments in sync

Over time, the data and metadata in your different environments drift apart. This makes deployments more challenging because there are more differences between the environments than just the changes your team has made. Not all environments will be exact replicas of production, but sandboxes need to have the latest changes that have been released to production, so that testing in those environments gives a more accurate indication of success in production.

It’s a core part of sandbox management to keep your environments in sync. There are two elements here:

1. Minimize drift in the first place. If you use Pipelines in Gearset, back propagating changes to keep all environments from rapidly getting out of sync is a painless and semi-automated process.
2. Periodically bring environments back into alignment with each other. Depending on the amount of drift between environments, different approaches may be needed — whether that’s a series of deployments or a full refresh. This process might happen between sprints or projects.

The culture of your team is also vital. Developers or admins cutting corners on the agreed process will mean environments get out of sync much faster. Preventing this from happening is a priority. A developer waiting for a series of slow automation jobs will be tempted to skip stages or find a workaround, so it’s essential to create a streamlined process. The team also needs to have a shared understanding of the value of CI/CD and the costs of other approaches.

Teams might decide that it’s more efficient — and safe — to change some metadata types directly in production. Clearly, these changes need to be pulled back to source control and propagated to all environments. With the exception of a few types (e.g. reports and dashboards), most changes should still be made in developer orgs or in a hotfix environment and released following the established CI/CD process. The pipeline should be efficient enough that creating work directly in production offers little advantage for speed of delivery.

Continuous delivery: accelerate the release cycle

The aim of CI/CD is to shorten your release cadence and speed up delivery to end users. It has the added advantage of automating processes and freeing up development and release teams, but that’s not the primary objective. There are several best practices that make sure the release pipeline stays fast-flowing.

Merge early and often

This is the heart of continuous integration (CI): merging small, logical units of work into version control at the earliest opportunity. Regularly merging work means developers discover early whether or not their work creates conflicts with others, and the whole team is working from a codebase that reflects the latest work from around the team. Failing to do this inevitably causes larger merge conflicts down the line that will slow progress and block releases.

Adopt “shift left” testing

A “shift left” approach to testing and validation means identifying any issues at the earliest possible stage in the development process. Rather than testing code late in the process, automated tests and static code analysis should be run throughout the release cycle — including in development environments. To maintain efficiency, test jobs and rulesets should be kept lean.

Merging early means integration problems will be flagged as soon as possible. With Gearset, validations against Salesforce orgs can be set to run as soon as a pull request is opened.

Increase release frequency

The key to successful automation is removing any obstacles and points of friction that stall or slow progress. Teams should prioritize addressing failures, with the aim of resolving any sticking points in their process and gradually upping their release frequency. High-performing Salesforce DevOps teams will release multiple times a day.

Businesses that are used to a slower release cadence may push back on more frequent releases, and the benefits should be explained to get buy-in. If it’s really not possible to release more often, perhaps because ensuring compliance is an unavoidable brake on deployments, release branches are a good way to get the benefits of continuous integration even with a slower release cadence.

Always be in a position to release

The essence of continuous delivery is being able to release on demand, so adopting CI/CD for Salesforce should mean that your main branch is always deployable to production. To achieve this objective, you’ll need to have confidence in your testing and validation setup processes. Some teams will go all the way to continuous deployment — meaning they automate deployments to production every time PRs are merged into main. But the best option for most teams is continuous validation against production, with human oversight over the final release.

Salesforce deployments are frustratingly error-prone, which is a real spanner in the works for automation. It’s one reason why teams struggle to make CI/CD work using tools like Jenkins and adopt Gearset as a purpose-built Salesforce CI/CD solution that works out of the box.

Security: protect your Salesforce orgs

Since DevOps teams are constantly working with Salesforce data and metadata, security should be baked into the process — this is the idea behind the term DevSecOps. But when working on your CI/CD process, it’s all too easy to overlook some essentials for maintaining resilience.

Back up your data and metadata

The unfortunate reality is that releases are one possible cause of damage to your Salesforce orgs, potentially causing both data and metadata loss. Being prepared for disaster recovery is absolutely fundamental and must be considered as part of a drive to improve DevOps processes like CI/CD. If you don’t have a proven backup and restore strategy in place, then you really shouldn’t be thinking about accelerating your automated releases to production just yet.

Monitor the whole CI/CD pipeline

It’s impossible to secure your release pipeline or ensure deployment process governance without complete visibility. You need to be able to see:

• The status of all environments in the pipeline
• Where deployment packages are in the pipeline
• Test and validation results for each stage of the release process
• A full history with enough context to serve as an audit trail
• Team performance against the DORA metrics to encourage continuous improvement
• Unauthorized changes made outside of the agreed process

This kind of visibility allows release managers to give sign off for deployments, and helps project managers track progress towards stage gates.

Test meaningfully

You should test everywhere in the release process and use automated testing where possible. But tests don’t mean anything if they’re not well written. Too many teams have unit tests that don’t really verify Apex classes execute as intended, because the tests were mainly written to meet Salesforce’s 75% code coverage threshold.

Checks and alerts are also of no value if the results are ignored by the team. Teams can get used to seeing (and ignoring) loads of test failures or static code analysis results. Important failures are lost in the noise. Having a focused set of tests and rule sets isn’t just more efficient — it also trains teams to care about and act on errors and warnings.

Salesforce CI/CD checklist for best practices

Environment management

• A full sandbox is used for pre-production tests.
• Scratch orgs are used where possible.
• Version control is the source of truth.
• The Git branching strategy matches process requirements.
• Changes in production and test environments are prevented.
• A process for keeping environments in sync is in place.

Continuous delivery

• Continuous integration is embedded in the culture.
• Tests are run in development environments.
• Failures are prioritized and learned from.
• Roles and responsibilities are defined with segregation of duties.
• There’s business buy-in for shorter release cycles (or release branches).
• Salesforce validations are triggered on pull requests.
• Continuous validation against production is in place.

Security

• Both data and metadata are backed up.
• The disaster recovery process is well tested.
• Teams and stakeholders can visualize the release pipeline.
• Unauthorized changes can be tracked and dealt with.
• Teams are willing to wait for automated test jobs.
• Quality gates ensure deployment governance.
• Test failures are actioned.

Salesforce CI/CD that really delivers

Whether you’re one of the many teams working towards Salesforce CI/CD, or you’re optimizing an existing process, continuous improvement is the key. Evaluate which best practices you’re acing, and which could use some attention, then incrementally improve your process.

All of the best practices described in this article can be achieved with Gearset. If you haven’t already, begin a free trial to get a feel for everything the platform has to offer or download our free CI/CD ebook to find out more.