Salesforce CI/CD — Best Practices for Development & Deployment
Overview
CI/CD (Continuous Integration / Continuous Deployment) is a structured approach to moving Salesforce changes from development through testing and into production in a controlled, automated, and repeatable way. Instead of making changes directly in a sandbox and deploying them straight to production — hoping nothing breaks — a CI/CD process introduces version control, peer review, automated testing, and a clear promotion path across environments.
- Why it matters: Without CI/CD, teams risk overwriting each other's work, deploying untested changes, losing the ability to roll back, and having no audit trail of what changed or why. A proper process protects the org, reduces risk, and scales with team size.
- What you'll learn: The recommended environment progression (Dev → SIT → UAT → Production), how code and configuration flow through each stage, the tools involved and their roles, how to bring admin-driven declarative changes into the process, and why this approach is significantly safer than ad-hoc deployments.
Why CI/CD Matters: Basic vs. Proper Deployment
Many Salesforce teams start with a simple approach: develop in a sandbox, then deploy straight to production using change sets or a direct deployment. This works for small teams with low complexity — but it introduces serious risk as the org, the team, or the stakes grow.
The table below highlights the key differences between a basic deployment approach (no repository, no formal process) and a proper CI/CD pipeline.
| Concern | Basic (Sandbox → Production) | CI/CD Pipeline |
|---|---|---|
| Version History | None — no record of what was deployed or when. If something breaks, you're guessing what changed. | Full Git history — every change is committed with a message, author, and timestamp. You can trace any issue to a specific commit. |
| Rollback Ability | No rollback path. If a deployment causes issues, you manually undo changes or restore from a backup (if one exists). | Roll back by redeploying a previous known-good commit from the repository. The "last working version" is always available. |
| Peer Review | No formal review. Changes go from one person's sandbox straight to production without a second set of eyes. | Pull requests require peer review before merging. Reviewers catch bugs, security gaps, and logic issues before they reach production. |
| Automated Testing | Tests may or may not run. No automated gate to prevent broken code from deploying. | Automated test execution on every PR. Deployments are blocked if tests fail — broken code cannot reach production. |
| Overwriting Others' Work | High risk. Multiple people deploying from different sandboxes can overwrite each other's changes without knowing. | Git detects merge conflicts before deployment. Two people changing the same file must resolve the conflict explicitly. |
| Audit Trail | Minimal. Salesforce Setup Audit Trail captures some changes, but it's limited and doesn't show the "why." | Complete trail — Git commits, PR discussions, approval records, and deployment logs create a full compliance-ready history. |
| Consistency Across Environments | Environments drift apart. What's in the sandbox may not match production, and there's no way to verify. | The repository is the single source of truth. Every environment is deployed from the same codebase, ensuring consistency. |
In a basic deployment, the sandbox is the source of truth — and it's a source of truth that can change without notice, has no history, and can't be recovered if something goes wrong. In a CI/CD pipeline, the Git repository is the source of truth — it's versioned, auditable, reviewable, and recoverable.
The Environment Progression
A well-structured Salesforce CI/CD pipeline promotes changes through a series of environments, each serving a distinct purpose. This ensures that nothing reaches production without being developed, tested, and validated.
Development Environment
Who: Developers and admins
What happens: This is where all feature work takes place. Each developer ideally works in their own Developer or Developer Pro sandbox (or scratch org) to avoid stepping on each other's work. Code is written in VS Code, declarative changes are made in the sandbox UI, and everything is committed to a feature branch in Git.
Key rule: No one develops directly in UAT or production. All work starts here.
SIT — System Integration Testing (Optional)
Who: Developers, technical leads, integration specialists
What happens: Multiple developers' feature branches are merged together and deployed to a shared sandbox to verify that their changes work together — especially when integrations with external systems are involved (APIs, middleware, ETL). SIT is where you catch conflicts between features before they reach business users.
If your Salesforce org integrates with external systems (ERP, marketing platforms, payment processors, data warehouses), SIT provides a dedicated environment to test those integration points. For orgs with no external integrations, teams often skip SIT and merge directly into UAT.
UAT — User Acceptance Testing
Who: Business users, product owners, QA
What happens: Changes are deployed to a Full Copy or Partial Copy sandbox that closely mirrors production data. Business stakeholders test against real-world scenarios to validate that the changes meet requirements. This is the final gate before production — if UAT passes, the change is approved for deployment.
Key rule: Developers do not "fix and redeploy" during UAT. If issues are found, the change goes back to Development for a fix, then re-promotes through the process.
Production
Who: End users
What happens: Approved changes are deployed to the live org. In a CI/CD pipeline, this deployment is triggered automatically when code is merged to the main branch (after passing all validation checks), or manually triggered during a planned release window depending on the team's release cadence.
The CI/CD Workflow
This is how a single change moves from idea to production. Each step in the workflow maps to a specific tool and environment.
main in Git (e.g., feature/discount-calc)main triggers production deployment — automated or during a release window.How Git Branches Map to Environments
A common and effective pattern is to map Git branches directly to Salesforce environments:
| Git Branch | Salesforce Environment | Trigger |
|---|---|---|
feature/* | Developer Sandbox | Manual deploy during development |
develop or sit | SIT Sandbox (if used) | Merge from feature branch |
uat | UAT Sandbox | Merge from feature or develop branch |
main | Production | Merge from UAT after sign-off |
When a PR is merged into the uat branch, an automated pipeline deploys to the UAT sandbox. When uat is merged into main, the pipeline deploys to production. This mapping creates a clear, auditable promotion path.
Tools and Their Roles
No single tool handles the entire CI/CD process. Each tool has a specific role, and they work together to form the full pipeline.
Choosing a CI/CD Approach
Teams generally choose one of three paths for managing their deployment pipeline:
| Approach | Best For | Trade-offs |
|---|---|---|
| Gearset | Mid-sized teams, fast setup, admin-friendly | GUI-driven, excellent support, more affordable. Less customizable than raw GitHub Actions. |
| Copado | Large enterprises, compliance-heavy orgs | Full ALM, rollback, robotic testing, strong governance. Higher cost and learning curve. |
| Salesforce CLI + GitHub Actions | Technical teams, full control | Maximum flexibility and customization. Requires YAML authoring, CLI expertise, and more maintenance. |
All three approaches use Git as the foundation. Even Gearset and Copado integrate with GitHub (or other Git providers) to store metadata in a repository. The repository is always the source of truth.
Capturing & Committing Declarative Changes
One of the biggest practical challenges in Salesforce CI/CD is that not all changes are made in code. Admins — and even developers — regularly use the Salesforce Setup UI to create or modify fields, permission sets, page layouts, validation rules, flows, and other declarative configuration. These changes exist only in the org until someone explicitly captures them and brings them into the repository.
If declarative changes aren't committed to Git, they exist outside the pipeline entirely — invisible to version control, unreviewable, and at risk of being overwritten by the next deployment from the repo.
The Retrieve-and-Commit Workflow
This is the recommended process for incorporating declarative changes into a CI/CD pipeline:
How Tools Help Bridge the Gap
Admins don't need to learn the CLI or Git to participate in this workflow. Both Gearset and Copado provide GUI-based interfaces that allow admins to:
- Compare their sandbox against the repository to see exactly what changed
- Select which changes to commit (ignoring noise like metadata reordering)
- Commit directly to a Git branch through a web interface — no terminal required
This lowers the barrier for admins to participate in the CI/CD process without changing how they work in Salesforce.
For teams using the CLI approach, a developer typically retrieves the admin's changes using sf project retrieve start, reviews the diff in VS Code, and commits on the admin's behalf — acting as a bridge between the Setup UI and the repository.
Preventing Org Drift
Even with a good process, changes sometimes bypass the pipeline — an admin makes a quick fix directly in production, or someone forgets to commit a sandbox change. This is called org drift: the gap between what's in the repository and what's actually in the org.
Best practices for managing drift:
- Scheduled org comparisons — Tools like Gearset and Copado can run automated comparisons between the repository and production on a regular cadence, flagging any metadata that exists in the org but not in Git.
- Nightly metadata backups — A scheduled job retrieves all production metadata and commits it to a backup branch, creating a safety net and an audit trail of org-side changes.
- Team discipline — Establish a clear rule: if it's not in the repo, it didn't happen. All changes — code or clicks — must flow through the pipeline.
Key Takeaways
| Principle | What It Means |
|---|---|
| The repo is the source of truth | Everything — code and configuration — lives in Git. If it's not committed, it's not real. |
| Promote, don't deploy | Changes move through environments (Dev → SIT → UAT → Prod) in a controlled progression. Nothing skips a stage. |
| Automate the gates | Tests, static analysis, and validation deployments run automatically on every PR. Humans review; machines enforce. |
| Admin changes belong in the pipeline too | Declarative changes made through the UI must be retrieved and committed to Git — using CLI, Gearset, or Copado. |
| Choose the right tooling for your team | Gearset and Copado offer GUI-driven CI/CD. CLI + GitHub Actions offers maximum control. All three use Git as the foundation. |
| Monitor for drift | Scheduled org comparisons and metadata backups catch changes that bypass the process — because they will happen. |