Improving the Salesforce development cycle in 2026 means treating your org like a real software project: Git is the source of truth, metadata lives in version control, and deployments are automated and tested rather than clicked through by hand. The teams that ship reliably have moved past change sets and the retired Force.com IDE to source-driven development with the Salesforce CLI, scratch orgs, packaging, and CI/CD.
This guide walks through the modern Salesforce DevOps toolchain and the practices that make releases faster and safer. We have been building and maintaining Salesforce orgs as part of our Salesforce consulting and development work for over 12 years and 50+ projects, and the pattern below is the one we keep coming back to. If you are still deciding who should own this, see how to choose a Salesforce consulting partner. New to the platform entirely? Start with what Salesforce is and what it does.
Why the old release process holds teams back
For years, Salesforce changes moved between orgs through change sets clicked together in the UI, or through the Ant Migration Tool and the Force.com IDE. Those tools are now legacy: the Force.com IDE is retired, the Ant/Metadata API workflow is fragile, and change sets cannot be diffed, reviewed, or rolled back.
The symptoms are familiar:
- No history of who changed what or why — there is no diff to review.
- Manual, error-prone deployments where components get missed and break production.
- No safe place to experiment; everyone shares a handful of sandboxes.
- Releases batched into rare, high-risk "big bang" events instead of small, frequent merges.
Modern Salesforce DevOps fixes this by moving the org's metadata into Git and automating the path from a developer's change to production.
Source-driven development with Salesforce DX
Salesforce DX (SFDX) reframes development around source files in a Git repo rather than a live org. The two building blocks are the new CLI and scratch orgs.
Use the sf CLI, not the old sfdx commands
The CLI you should standardise on is the v2 sf executable. The older sfdx force:... command set is superseded — the namespaced force: topics are deprecated and the modern equivalents read more clearly (for example sf project deploy start instead of sfdx force:source:deploy). Install it once and keep it updated:
# Install / update the Salesforce CLI (the v2 "sf" executable)
npm install --global @salesforce/cli
sf --version
# Authorize your Dev Hub once (enables scratch orgs + packaging)
sf org login web --set-default-dev-hub --alias DevHub
# Spin up a disposable scratch org from your project definition
sf org create scratch \
--definition-file config/project-scratch-def.json \
--alias feature-org --set-default --duration-days 7
# Push source metadata into the scratch org, then pull declarative changes back
sf project deploy start
sf project retrieve start
# Run Apex tests locally with code coverage before you open a PR
sf apex run test --code-coverage --result-format human --wait 10Source format, scratch orgs, and packaging
A DX project stores metadata in source format — small, mergeable files instead of one giant Metadata API blob — which makes Git diffs and code review actually work.
Scratch orgs are short-lived, configurable orgs created from a definition file and your source. Because they are disposable and reproducible, each developer (or each feature branch, or each CI run) gets a clean org built from version control, with no leftover state from the last person who touched it.
For shipping reusable functionality, unlocked packages (2GP) let you bundle metadata into versioned, installable units with explicit dependencies. Org-dependent unlocked packages are an option when your metadata cannot be cleanly extracted from a large, mature org. Packaging turns "deploy a pile of components" into "install version 1.4.0", which is far easier to track and roll back.
Make Git your single source of truth
Once metadata lives in source format, Git becomes the system of record. Every change flows through a branch, a pull request, and a review before it reaches production — exactly like any other engineering team.
A workable branching model for most teams:
mainmirrors production.- A long-lived integration branch (e.g.
develop) maps to a UAT/integration sandbox. - Short-lived
feature/*branches map to scratch orgs or developer sandboxes. - Pull requests trigger automated validation (check-only deploy + Apex tests) before merge.
Scratch orgs vs sandboxes
You do not have to choose only one — most teams use scratch orgs for isolated feature work and sandboxes for integration, UAT, and staging. The trade-offs:
| Aspect | Scratch orgs | Sandboxes |
|---|---|---|
| Lifespan | Disposable (up to 30 days) | Long-lived, refreshed on a schedule |
| Created from | Source + definition file (reproducible) | A copy of your production org |
| Data | Empty; you seed test data | Config only, or partial/full prod data (by type) |
| Best for | Feature dev, CI runs, packaging | Integration, UAT, staging, training, full regression |
| Setup | sf org create scratch ... in seconds |
Provisioned and refreshed from production |
| Requires | An enabled Dev Hub | A sandbox-eligible edition/license |
Rule of thumb: build and test a feature in a scratch org, then validate the merged result in a sandbox that mirrors production before release.
Automate deployments with CI/CD
The biggest single win for the dev cycle is replacing manual deploys with a pipeline. There is a spectrum of options, from free Salesforce-native tooling to full commercial platforms.
Salesforce DevOps Center (the free successor to change sets)
DevOps Center is Salesforce's free, generally available product that replaces change sets. It gives you a UI on top of a Git-backed flow: track work items, see what changed, and promote changes between environments through a pipeline — without everyone needing to live in the CLI. It is the right starting point for teams leaving change sets who are not ready to hand-roll CI.
Roll your own with GitHub Actions or GitLab CI
If your team is comfortable with Git, a CI runner (GitHub Actions, GitLab CI, Azure Pipelines) plus the sf CLI gives you full control. A pull request runs a check-only validation deploy with tests, and a merge to main runs the real deploy. If you offload heavier build steps or self-hosted runners onto cloud infrastructure, our AWS consulting services cover that side. A minimal validation job looks like this:
# .github/workflows/salesforce-ci.yml
name: Salesforce CI
on: [pull_request]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Salesforce CLI
run: npm install --global @salesforce/cli
- name: Authenticate to the target org
run: echo "$SF_AUTH_URL" | sf org login sfdx-url --sfdx-url-stdin --alias ci
env:
SF_AUTH_URL: ${{ secrets.SF_AUTH_URL }}
- name: Validate deployment (check-only) and run local tests
run: sf project deploy start --dry-run --test-level RunLocalTests --target-org ciCommercial DevOps platforms
When you outgrow hand-rolled pipelines, dedicated platforms add automation and guardrails on top of Git. The main players are Gearset, Copado, Flosum, and AutoRABIT — all paid, per-seat SaaS products (pricing is published on each vendor's site and changes over time, so verify there rather than relying on a number here).
| Capability | DevOps Center (free) | Commercial platforms (Gearset / Copado / Flosum / AutoRABIT) |
|---|---|---|
| Cost model | Free, Salesforce-native | Paid, per-seat subscription |
| Metadata diff & deploy | Yes (UI-driven) | Yes, with richer comparison and conflict handling |
| Pipeline automation | Basic promotion flow | Advanced multi-stage pipelines, approvals, gates |
| Automated backups | No | Yes (org/metadata + data backup & restore) |
| Static analysis built in | No (add it yourself) | Often bundled (PMD, security scanning) |
| Data/test-data seeding | No | Yes |
| Best for | Teams leaving change sets | Larger teams, regulated industries, complex orgs |
There is no single "correct" choice. Small teams can go a long way on DevOps Center plus a CI runner; larger or regulated orgs usually justify a commercial platform for its backups, approvals, and audit trail.
Build in quality: testing and static analysis
Faster releases are only safe if quality is automated. Salesforce gives you several layers.
Apex unit tests and the 75% coverage rule
This one is non-negotiable and worth stating plainly: to deploy Apex to a production org, your org must have at least 75% Apex code coverage, and every trigger must have some coverage. Treat 75% as the floor, not the goal — write meaningful assertions, not filler tests that exercise lines without checking behaviour. Run the suite in CI on every pull request so coverage and failures are caught before merge.
Static analysis with the Salesforce Code Analyzer and PMD
Run the Salesforce Code Analyzer (the sf CLI plugin that unifies engines including PMD for Apex, ESLint, and security rules) to catch governor-limit risks, SOQL-in-loops, and security anti-patterns automatically. Wiring this into CI keeps the whole team honest. Many of the issues it flags map directly onto the platform's hard limits — see our deep dive on Salesforce governor limits for what those rules are protecting you from.
LWC Jest tests for the front end
Lightning Web Components ship with Jest support via @salesforce/sfdx-lwc-jest. Unit-test component logic and rendering the same way you would any JavaScript front end, and run those tests in the same CI pipeline as your Apex tests. (Stick to JavaScript for LWC tests and component code.)
Practices that compound over time
Tools enable the dev cycle; habits are what actually speed it up.
- Release small and often. Frequent, small merges are easier to review, test, and roll back than rare big-bang releases. Pair this with feature branches that are short-lived.
- Have an explicit environment strategy. Know exactly which sandbox maps to which branch and stage (dev → integration → UAT → production), and refresh sandboxes on a schedule so they do not drift from production.
- Prefer metadata-driven configuration. Custom metadata types and custom settings let you change behaviour by deploying configuration rather than editing and redeploying code — fewer code releases, fewer regressions.
- Automate regression testing. Combine Apex tests, LWC Jest, and (where it pays off) UI/end-to-end tests so a green pipeline genuinely means "safe to ship".
- Follow customization best practices. Clean, well-structured metadata is what makes all of the above sustainable — see our notes on Salesforce customization best practices and, on the data side, how to run a SOQL query in Salesforce efficiently.
A reference workflow, end to end
Putting the pieces together, a healthy 2026 Salesforce dev cycle looks like this:
- A developer creates a
feature/*branch and spins up a scratch org from source. - They build the change (declarative + code), pull declarative changes back into source with
sf project retrieve start, and commit. - Opening a pull request triggers CI: a check-only validation deploy, Apex tests at
RunLocalTests, LWC Jest, and the Code Analyzer. - A teammate reviews the diff in Git and approves.
- Merging to the integration branch deploys to a UAT sandbox for end-to-end validation.
- Merging to
main(via DevOps Center or your CI pipeline) deploys to production, with backups and an audit trail in place.
Each step is small, reviewed, and automated — which is exactly why it is faster and safer than the change-set era it replaced.
Frequently Asked Questions
Should I use the sf or sfdx CLI?
Use sf — the v2 Salesforce CLI. The older sfdx force:... namespaced commands are superseded and being phased out; the modern equivalents (e.g. sf project deploy start, sf apex run test) are clearer and actively maintained. Install it with npm install --global @salesforce/cli.
Scratch orgs or sandboxes — which should I use?
Both, for different jobs. Scratch orgs are disposable, reproducible orgs built from source — ideal for isolated feature development, CI runs, and packaging. Sandboxes are long-lived copies of production — ideal for integration, UAT, staging, and full regression. Build features in a scratch org, then validate the merged result in a production-like sandbox before release.
Is Salesforce DevOps Center free?
Yes. DevOps Center is a free, generally available Salesforce product and is the official successor to change sets. It provides a Git-backed, UI-driven pipeline for tracking and promoting changes, so it is the natural first step for teams leaving change sets without building their own CI.
Do I actually need Gearset or Copado?
Not necessarily. Many teams ship reliably on free tooling — DevOps Center, or the sf CLI plus GitHub Actions/GitLab CI. Commercial platforms like Gearset, Copado, Flosum, and AutoRABIT (all paid, per-seat) earn their keep on larger or regulated orgs by adding automated backups, approval gates, richer diffs, data seeding, and audit trails. Start free, adopt a platform when those needs are real.
What is the Apex test coverage requirement?
To deploy Apex to production, your org needs at least 75% Apex code coverage, and every Apex trigger must have at least some coverage. Treat that as a minimum and focus on meaningful assertions rather than tests that merely run lines. Running the test suite in CI on every pull request keeps you safely above the threshold.
How do I add CI/CD to Salesforce?
Put your metadata in Git in source format, then either use DevOps Center for a no-code pipeline, or wire up a CI runner (GitHub Actions, GitLab CI) with the sf CLI. On a pull request, run a check-only validation deploy (sf project deploy start --dry-run --test-level RunLocalTests) plus your LWC Jest tests and the Code Analyzer; on merge to main, run the real deploy to production.