Salesforce CI/CD and Release Management
A reference pipeline for Salesforce: source control, scratch orgs and sandboxes, tests, static analysis, deployment and rollback, plus Marketing Cloud and AI developer aids.
A Salesforce CI/CD architecture turns changes into releases you can repeat: every change in source control, tested automatically, deployed the same way to each environment, and reversible when something goes wrong. Salesforce adds its own wrinkles, including metadata that does not deploy cleanly, three platform releases a year, and Marketing Cloud assets that follow a different path from the core platform. This page is a reference design; we validate the APIs, edition and permissions for each implementation.
Business context
Teams usually feel the need for CI/CD after a bad release: a change set missed a field, a flow was edited in production, or a hotfix overwrote someone else's work. The aim is not tooling for its own sake. It is a short, reliable path from an idea to production with evidence at each step, so releases become routine.
Tooling and naming as of October 2026
- Salesforce CLI (
sfv2) ships a stable release every Wednesday; the latest stable release is 2.155.7 (21 October 2026). The oldsfdx(v7) receives no updates. Secrets are redacted from CLI output; the temporarySF_TEMP_SHOW_SECRETSworkaround ends with the release candidate dated 28 October 2026, so usesf org auth show-*instead.api request rest/graphqlneeds Node.js 22 or later. - DevOps Center is labelled "Lifecycle Center (formerly DevOps Center)" in Salesforce's Winter '27 platform blog, which describes Coding Agent Governance and Deployment (policy enforcement, approvals and audit logs for agent-generated code) as GA. Trailhead and Help still say DevOps Center.
- Testing: Flow Test Mode and mock outputs are Beta in Winter '27, and Apex
@IntegrationTestis a Developer Preview. - Salesforce DX MCP Server (
@salesforce/mcp) is an open-source developer aid that lets AI coding assistants work with orgs already authorised in the CLI. It was a Developer Preview in June 2025 and labelled Beta in the Spring '26 developer guide; current docs track maturity per tool (GA or NON-GA), and whole-server GA is not confirmed, so treat its status as not confirmed.
GeekMidst can design and implement this pipeline. See Salesforce DevOps and release management.
Salesforce CI/CD reference architecture
Reference architecture: a reusable pattern, not a live client integration
Select a component to see what it is responsible for and how data moves to and from it.
Components and data flows (text version)
| Component | Type | Responsibility |
|---|---|---|
| Developers and adminsVS Code, Web Console, CLI | People | Make changes in scratch orgs or developer sandboxes and commit them to source control. No direct edits in production. |
| AI coding aidsSalesforce DX MCP Server | AI and agents | Local, open-source MCP server that works with CLI-authorised orgs. The --orgs flag is required; NON-GA tools need --allow-non-ga-tools. Status not confirmed. |
| Source controlbranches and pull requests | Integration layer | The single source of truth for metadata and configuration. Every change arrives as a reviewed pull request. |
| Scratch orgs and dev sandboxesshort-lived environments | Salesforce product | Isolated places to build and test a change. Scratch orgs are created from source; sandboxes hold more realistic configuration. |
| CI pipelinesf CLI, static analysis, tests | Integration layer | Validates every pull request: static analysis, Apex and Flow tests, and a check-only deployment to a test org. |
| DevOps CenterLifecycle Center in Winter '27 | Salesforce product | Salesforce's own release tool for work items and promotion between environments; suits teams that prefer clicks to scripts. |
| UAT and staging sandboxesrelease candidates | Salesforce product | Business testing on masked data, regression packs and release rehearsals during each Salesforce preview window. |
| Production orgdeploy, monitor, roll back | Salesforce product | Receives only pipeline deployments, in a release window, with a rollback plan for every release. |
| Marketing Cloud Engagementseparate deployment path | Salesforce product | Journeys, automations, content and data extensions do not deploy through the core Metadata API; they follow their own process. |
Data flows
- Developers and admins → Scratch orgs and dev sandboxes: build and test. Develop in an isolated org; recreate it from source when it drifts.
- AI coding aids → Scratch orgs and dev sandboxes: assisted changes. Point the DX MCP Server at scratch orgs or sandboxes only, never at production; review every change it proposes.
- Developers and admins → Source control: pull requests. Changes are committed on a branch and reviewed by a second person before merge.
- Scratch orgs and dev sandboxes → Source control: retrieve metadata. Changes made in an org are retrieved into source so nothing lives only in an org.
- Source control → CI pipeline: PR triggers. Each pull request starts validation; a failed check blocks the merge.
- Source control → DevOps Center: work items. DevOps Center works from your repository so both routes share one source of truth.
- CI pipeline → UAT and staging sandboxes: validated deploy. Deploys the merged release candidate to UAT. On failure the pipeline stops and reports the component.
- DevOps Center → UAT and staging sandboxes: promote. Promotion through the pipeline stages, with approvals.
- CI pipeline → Production org: release deploy. Deploys the same artefact tested in UAT, in an agreed window.
- UAT and staging sandboxes → Production org: sign-off. Business sign-off and a passed regression pack are required before release.
- CI pipeline → Marketing Cloud Engagement: Marketing Cloud steps. Scripted or manual steps for Marketing Cloud assets, checked against a release checklist.
- Production org → Source control: hotfix back-merge. Emergency fixes are made in source and merged back, so the next release does not undo them.
Component responsibilities
| Component | Responsible for | Gate |
|---|---|---|
| Source control | History, review and branching | Pull request approved |
| Scratch orgs and sandboxes | Isolated build and test | Change works in isolation |
| Static analysis | Code quality and security rules for Apex and LWC | No new high-severity findings |
| Automated tests | Apex tests, Flow tests and agent tests where used | Agreed pass rate and coverage |
| CI pipeline | Validation and repeatable deployment | Check-only deploy passes |
| DevOps Center | Click-based promotion for admins | Approvals recorded |
| UAT | Business and regression testing | Sign-off |
| Production | Running the release | Smoke tests pass |
Data flow, step by step
- A developer creates a scratch org from source and builds the change.
- The change is retrieved into a branch and a pull request is opened.
- CI runs static analysis, Apex and Flow tests and a check-only deployment.
- After review and merge, the pipeline deploys the release candidate to UAT for business testing.
- In the release window, the same artefact is deployed to production and smoke-tested.
- Marketing Cloud steps run from the release checklist, and the release is tagged in source control.
Trust boundaries and authentication
The pipeline authenticates to each org as a dedicated deployment user with only the permissions it needs. Salesforce has said connected apps support ends in Summer '27, so set up pipeline authentication on External Client Apps, and note that refresh tokens expire after 30 days of inactivity from 4 November 2026 in production, which affects jobs that run rarely. Keep credentials in the CI system's secrets store. AI aids such as the DX MCP Server use orgs already authorised on the developer's machine, so limit them with the --orgs flag to development orgs; its write tools include deploy_metadata and assign_permission_set, which need human review.
Failure scenarios and how to handle them
| Scenario | Effect | Handling |
|---|---|---|
| Deployment fails midway | Release blocked | Validate ahead of the window and confirm your deployment settings roll back on error |
| Bad change reaches production | Broken process | Redeploy the previous tagged version, or switch the feature off with a custom metadata flag |
| Data damaged by a release | Lost or wrong records | Back up before release; Backup and Recover is a Guardian add-on |
| Salesforce release changes behaviour | Tests fail after upgrade | Run regression packs in preview sandboxes |
| Old API versions in metadata | Future deployment errors | API versions 31.0 to 40.0 are deprecated in Summer '27 and retired in Summer '28; update them |
| Marketing Cloud SQL activity keeps failing | Automation stops | SQL Query activities deactivate after 24 consecutive failures; monitor and alert |
Marketing Cloud deployment considerations
Marketing Cloud Engagement assets, such as journeys, automations, Content Builder assets, data extensions and CloudPages, follow a separate path from core metadata. Keep their code (AMPscript, SSJS and SQL) in source control, document the configuration steps, and test in a separate business unit or account where available before production. The Marketing Cloud Engagement MCP Server, GA since 2 June 2026, creates journeys in Draft and annotates destructive tools, which can help with repetitive set-up, but changes still need review. Marketing Cloud Next runs on the core platform, so more of its configuration can follow the core pipeline; check each component. See testing and deploying Marketing Cloud Next solutions.
Operational monitoring
Track deployment frequency, failure rate, time to restore and test pass rate. After each release, watch error logs, flow failures and integration error rates for 24 hours. Custom Salesforce Hosted MCP Server definitions are deployable metadata too, so include them in the same pipeline if you use them.
Alternative approaches and trade-offs
- Change sets. No set-up, but no version control, no automated pipeline checks and no rollback. Compare options in change sets, SFDX and DevOps Center.
- DevOps Center only. Good for admin-heavy teams; add CI for automated checks as the codebase grows.
- Third-party DevOps platforms. Rich features at extra cost; check fit with your branching model.
Implementation checklist
- 01
Put everything in source control
Metadata, Marketing Cloud code and configuration notes.
- 02
Choose a branching model
Keep it simple enough for admins to follow.
- 03
Set up environments
Scratch orgs or sandboxes per developer, plus UAT and staging.
- 04
Automate checks
Static analysis, Apex and Flow tests and check-only deployments on every pull request.
- 05
Secure pipeline access
Dedicated deployment users, External Client Apps and stored secrets.
- 06
Plan rollback
Tagged releases, feature flags and backups before each release.
- 07
Rehearse with each Salesforce release
Run regression packs in preview sandboxes.
Related services and solutions
DevOps and release management
Pipeline design and implementation
→Salesforce DevOps and MCP
AI developer aids, used safely
→Testing and QA
Test strategy and automation
→Release readiness checklist
Pre-release checks
→Release testing checklist
Practical regression testing
→Multi-cloud architecture
Coordinating releases across platforms
→Questions we hear
Is DevOps Center now called Lifecycle Center?
Is the Salesforce DX MCP Server generally available?
Can we roll back a Salesforce deployment?
Do Marketing Cloud Engagement assets fit the same pipeline?
Sources
- https://www.salesforce.com/blog/platform-winter-27-release/
- https://raw.githubusercontent.com/forcedotcom/cli/main/releasenotes/README.md
- https://github.com/salesforcecli/mcp
- https://developer.salesforce.com/docs/atlas.en-us.264.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_mcp_server.htm
- https://developer.salesforce.com/blogs/2026/10/developers-guide-to-the-winter-27-release
- https://developer.salesforce.com/blogs/2026/06/the-mcp-server-for-marketing-cloud-engagement-is-now-ga
Make releases routine
We can design your pipeline, environments, test gates and rollback plan, including Marketing Cloud steps. Consultations are remote, from India.
