Salesforce CI/CD best practices

Getting CI/CD right on Salesforce means working with the platform’s unique technical setup. Unlike traditional software platforms, Salesforce is metadata-driven — with application logic spread across both declarative configurations (such as Flows and page layouts) and programmatic code (Apex and Lightning Web Components). You need to version and deploy these changes together.

Salesforce teams often work across multiple orgs — developer orgs, sandboxes, and production — rather than a single runtime environment. Deployments rely on asynchronous Metadata API calls that handle XML-based file packages, which means polling, state management, and validation complexity that standard CI/CD tools aren’t built for.

Despite these differences, the goals remain the same: faster delivery, early issue detection, and better collaboration. Achieving them requires adapting DevOps practices to Salesforce’s architecture and reinforcing a strong DevOps culture across your team. That’s what we’ll cover in this article.

If you want to learn more about scaling your Salesforce CI/CD pipeline, join our upcoming webinar on March 26th and explore what good Salesforce CI/CD looks like at scale, and how to get there without starting from scratch.

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

Effective environment management is foundational to a reliable CI/CD process. Coordinating orgs, version control, and metadata so that changes move predictably from development to production takes deliberate planning — especially given how many environment types and metadata dependencies are at play.

You need to decide which orgs are used where, what Git branching strategy to adopt, and 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.

Use version control as your source of truth

Git should be the source of truth, not just a metadata backup. All metadata and code changes that can be exported via the Metadata API should be tracked in Git. Though there are some configuration types — such as reference data in custom objects, certain platform features, and non-API-exposed settings — that will need manual management or specialist tools alongside Git-based version control.

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

• Use consistent branch naming to clearly map work to features or tickets, reducing confusion during deployments.
• Commit small, logical changes frequently to limit metadata conflicts and make dependency issues easier to diagnose.
• Annotate commits clearly so you can trace changes back to business requirements or incidents.
• Keep all feature changes in a single branch to avoid partial deployments that break metadata dependencies.
• Use pull requests and peer reviews to catch issues early, especially in declarative metadata.
• Protect key branches to prevent accidental overwrites or bypassing validation.
• Keep feature branches short-lived to reduce conflicts caused by sandbox refresh cycles.
• Delete merged branches to keep repositories clean and focused.

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.

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, our Salesforce CI/CD solution, 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 goal of continuous delivery is straightforward: keep production-ready changes deployable at all times through automated validation, testing, and controlled releases. This enables a shorter release cadence, speeding up delivery to end users, and reduces deployment risk.

A reliable process covers the full deployment cycle:

• Pre-deployment validation: Validate changes against the target org using validation-only deployments — this checks metadata dependencies, permissions, and test execution without modifying anything.
• Deployment execution: Deploy approved changes in the correct order to respect Salesforce metadata dependencies and the mix of declarative and programmatic components.
• Error handling: When deployments fail, capture them automatically with clear logs identifying dependency issues, test failures, or governor limit breaches — and fix them in source control, not by patching manually.
• Post-deployment verification: Run automated smoke tests after each deployment to confirm critical functionality still works as expected.

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 should 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.

Accelerating your automated releases to production also means considering automated backups of both data and metadata, taken regularly and before deployments, so that you’ve got an up-to-date backup to restore from if anything goes wrong. You’ll need to test your restore procedures too, so you can recover quickly from failed deployments, misconfigurations, or human error.

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.

Monitoring doesn’t stop once changes reach production either. You should actively monitor for post-deployment issues — org health and security posture, user impact signals, performance metrics, and error logs and automation failures across Apex, Flows, and integrations.

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’s Salesforce CI/CD solution. 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.