CI/CD & Deployment Strategy

CI/CD in Salesforce differs significantly from traditional software CI/CD. The platform’s metadata-driven architecture, shared sandbox environments, and org-based development model create unique challenges. The deployment strategy must balance automation, safety, and team velocity.

Foundational Context

For foundational CI/CD and version control concepts (Git branching, basic pipeline stages, introduction to continuous integration), see Git and GitHub for Administrators (Trailhead) and Continuous Integration (Trailhead). This page covers architect-level decisions: which branching strategy fits Salesforce metadata constraints, when to choose packages over CLI deploys, and how to design deployment pipelines for enterprise-scale orgs.

Git Branching Strategies

GitFlow vs Trunk-Based Development

The right branching strategy depends on team size, release cadence, and Salesforce-specific constraints.

Figure 1. GitFlow’s develop and release branches suit scheduled Salesforce releases where multiple features must be staged together. Trunk-based development cuts merge conflict risk but demands mature CI/CD automation and feature flags to keep main deployable at all times.

Factor	GitFlow	Trunk-Based
Release cadence	Scheduled releases (monthly, quarterly)	Continuous deployment
Team size	Large teams (10+)	Small to medium teams
Branch lifetime	Long-lived (days to weeks)	Short-lived (hours to days)
Merge conflicts	Higher risk due to long-lived branches	Lower risk with frequent integration
Salesforce fit	Better for change set mentality	Better for package-based development
Complexity	Higher, more branches to manage	Lower, fewer branches
Hotfix path	Dedicated hotfix branch	Direct to main with feature flag

CTA Recommendation

For most enterprise Salesforce teams, a modified GitFlow works best: main (production), develop (integration), and short-lived feature branches. Avoid pure trunk-based unless the team has strong CI/CD automation and high test coverage. Salesforce metadata makes merge conflicts more painful than in traditional codebases.

Recommended Branch Structure

main              ← Reflects production state
├── develop       ← Integration branch, deployed to SIT
│   ├── feature/JIRA-123-cpq-pricing    ← Individual feature work
│   ├── feature/JIRA-456-case-routing   ← Individual feature work
│   └── feature/JIRA-789-lead-scoring   ← Individual feature work
├── release/2024-Q4  ← Release candidate, deployed to UAT/Staging
└── hotfix/JIRA-999-email-fix  ← Emergency production fix

Salesforce DX CLI

The Salesforce CLI (sf) is the foundation of modern Salesforce DevOps.

sfdx is deprecated - use sf (v2)

The sfdx CLI (v7) was deprecated in July 2023. Salesforce no longer publishes updates to it (except security fixes). All new features and plugin updates are exclusive to sf (v2). The sfdx-style commands still execute in sf but are deprecated; reference documentation was removed in June 2024.

Key command migrations for CI/CD scripts:

sfdx (deprecated)	sf (current)
sfdx force:source:push	sf project deploy start
sfdx force:source:pull	sf project retrieve start
sfdx force:org:create --type scratch	sf org create scratch
sfdx force:org:create --type sandbox	sf org create sandbox
sfdx force:apex:test:run	sf apex run test
sfdx force:package:create	sf package create
sfdx force:package:version:create	sf package version create
sfdx force:package:install	sf package install

Migration path: Uninstall sfdx (v7), install sf (v2). Existing sfdx-style commands continue to work as aliases during transition, but update CI/CD pipeline scripts to sf-style commands to avoid future breakage. See Move from sfdx (v7) to sf (v2).

Key CLI Commands for CI/CD

Command	Purpose	Pipeline Stage
sf org create scratch	Create scratch org for testing	Build
sf project deploy start	Deploy source to an org	Deploy
sf project retrieve start	Retrieve metadata from org	Development
sf apex run test	Execute Apex unit tests	Test
sf package create	Create an unlocked package	Package
sf package version create	Create a new package version	Package
sf package install	Install a package into an org	Deploy
sf org delete scratch	Clean up scratch org	Cleanup

Source vs Metadata Format

• Source format: Decomposed into individual files (field per file, not all fields in one XML). Produces meaningful diffs and reduces merge conflicts.
• Metadata format: Monolithic XML files (all fields in one CustomObject.object-meta.xml). Legacy format, harder to diff and merge.

Always Use Source Format

All new Salesforce DX projects should use source format. The Salesforce CLI supports both, but source format produces meaningful git diffs and reduces merge conflicts. If inheriting a metadata-format project, invest in converting to source format.

Deployment Mechanism Comparison

Salesforce provides multiple ways to move metadata between orgs. The right choice depends on team maturity, org complexity, and governance needs.

Figure 2. The migration path from change sets to CLI to unlocked packages is incremental, not a single cutover. DevOps Center provides a GUI on-ramp for admin-heavy teams, while Copado and Gearset add compliance audit trails for enterprise governance requirements.

Mechanism	Rollback	Version History	Automation	Dependency Mgmt	Best For
Change Sets	Manual undo only	None	None	None	Small admin teams, simple changes
Salesforce CLI	Redeploy previous	Git history	Full CI/CD	Manual (package.xml)	Dev teams with CI/CD pipelines
Unlocked Packages	Install prior version	Package versions	Full CI/CD	Automatic	Large orgs, modular architecture
DevOps Center	Via Git history	Git + UI tracking	Partial	Manual	Mixed admin/dev teams
Copado / Gearset	Tool-managed	Full audit trail	Full CI/CD	Tool-managed	Enterprise compliance needs

DevOps Center and DevOps Testing

DevOps Center is Salesforce’s platform-native approach to change management. It provides a UI layer over Git-based source control. DevOps Testing (GA) extends it with automated quality gates.

DevOps Center Core Capabilities

• Change tracking: Track work items from development through deployment in a centralized UI
• Git integration: Built-in source control. Admins and developers see the same change history without learning Git CLI
• Pipeline management: Promote changes across environments (dev to staging to production) with clicks
• Conflict detection: Flags conflicting metadata changes across team members before promotion
• Mixed-team support: Declarative (admin) and programmatic (developer) changes managed in one workflow

DevOps Testing (GA)

DevOps Testing unifies Salesforce and partner testing tools into a single quality-gate framework:

Capability	What It Provides	Status
Test strategy definitions	Define which tests run at each pipeline stage	GA
Automated quality gates	Block promotions that fail test thresholds	GA
Code Analyzer v5	Static code analysis integrated into quality gates	GA
Scale Test	Performance and scale testing for deployment validation	GA
Partner integrations	ACCELQ, Copado, Panaya, Provar, Quality Clouds, Tricentis	GA
Apex Unit Tests	Unified Apex test results in the DevOps Testing dashboard	Coming soon
Flow Tests	Flow test results integrated into quality gates	Coming soon
Agentforce Testing Center	Test Agentforce agents with synthetic data before deployment	Coming soon

Agentforce Testing Center

Agentforce (formerly Einstein Copilot) Testing Center provides lifecycle management tooling for testing autonomous AI agents at scale. Teams evaluate agent responses and actions using synthetically generated data, with monitoring of usage and feedback. As Agentforce agents become more common in CTA scenarios, testing them before deployment is an architectural requirement, not optional.

DevOps Center vs Third-Party Tools

Factor	DevOps Center	Copado	Gearset
Cost	Included with Salesforce	Licensed ($$-$$$)	Licensed ($$)
Setup complexity	Low (native UI)	High (full ALM configuration)	Low-moderate
Git management	Built-in, UI-based	Full Git integration	Full Git integration
Metadata dependency detection	Basic	Manual dependency management	Automatic dependency detection
Compliance / audit trails	Basic	Strong (built-in compliance tracking)	Moderate
Advanced pipeline features	Limited (linear promotion)	Full (parallel pipelines, branching strategies)	Full (flexible pipelines)
Rollback	Via Git history	Tool-managed	Tool-managed with comparison
Best for	Teams moving off change sets; mixed admin/dev teams	Large enterprises with strict compliance (finance, healthcare)	Mid-size teams prioritizing fast setup and smart diffing

CTA Exam Relevance

When the scenario describes a team transitioning from change sets, DevOps Center is the lowest-friction first step. It introduces Git-based source control without requiring CLI skills. Recommend third-party tools (Copado, Gearset) when the scenario calls for advanced pipeline orchestration, compliance audit trails, or automatic metadata dependency resolution at enterprise scale. DevOps Center does not replace full CI/CD in complex implementations.

Change Sets: When They Are Still OK

Change sets are the legacy deployment mechanism. CTA scenarios may describe orgs still relying on them.

When Change Sets Are Acceptable

• Very small teams (1-2 admins) with simple release processes
• Admin-only changes (page layouts, validation rules, simple flows)
• One-time migrations or configuration changes
• Orgs without source control (though this itself is a problem to fix)

When to Move Beyond Change Sets

Change Set Limitation	Why It Matters
No rollback capability	Cannot undo a deployment without manual effort
No version history	Cannot track what was deployed when
Manual component selection	Human error in selecting components
No dependency validation	Missing components cause deployment failures
No automated testing	Tests run only if manually included
One-directional (no retrieve)	Cannot pull changes back to source control
No diff/comparison	Cannot review what changed before deploying

CTA Exam Context

If the scenario mentions change sets, the review board may be testing whether you recommend modernizing to CLI/package-based deployment. Acknowledge the current state, explain the risks, and propose a migration path. Do not propose ripping out change sets overnight.

Unlocked Packages

Unlocked packages are Salesforce’s recommended approach for organizing and deploying metadata in large implementations.

Package Types

Package Type	Use Case	Namespace	Upgradable
Unlocked (no namespace)	Internal org development	No	Yes
Unlocked (with namespace)	Shared across orgs	Yes	Yes
Managed	ISV distribution (AppExchange)	Yes (permanent)	Yes

Benefits of Unlocked Packages

• Dependency management: Packages declare dependencies on other packages
• Versioning: Each package version is a deployable artifact
• Rollback: Install a previous version to rollback
• Modular architecture: Organize org metadata into logical packages
• CI/CD friendly: Package creation can be automated in pipelines

Package Architecture Example

Figure 3. Organizing metadata into domain packages with a shared Core dependency lets teams deploy Sales and Service changes independently without touching shared data model components. The Core package becomes the contract all other packages depend on.

Package Dependency Graph and Versioning

In enterprise implementations, packages form a dependency graph. Changes must respect the dependency order: base packages are built and promoted first, then dependent packages.

Figure 4. The CI/CD build order must respect the dependency graph: Core is always built and promoted first. A package version pinning a minimum Core version means any Core patch below that floor will block installation of dependent packages in production.

Package versioning follows semantic versioning (Major.Minor.Patch.Build):

Version Part	When to Increment	Example
Major	Breaking changes, removed components	1.0 to 2.0
Minor	New features, non-breaking additions	2.0 to 2.1
Patch	Bug fixes, minor improvements	2.1.0 to 2.1.1
Build	Auto-incremented by Salesforce	2.1.1.1 to 2.1.1.2

Package Promotion

Only promoted package versions can be installed in production. A promoted version is immutable; it cannot be modified. Always validate a package version in a staging sandbox before promoting it. Rolling back requires installing the previous promoted version, which may fail if the new version added required components.

CI/CD Tools Comparison

Salesforce-Specific CI/CD Tools

Tool	Type	Strengths	Considerations
GitHub Actions	General CI/CD	Free for public repos, flexible, strong community	Requires custom SF workflow setup
Copado	SF-native DevOps	Built for Salesforce, user stories, compliance	License cost, vendor dependency
Gearset	SF DevOps	Excellent diff/merge, comparison tools	License cost, external dependency
Flosum	SF-native DevOps	Native on platform, no external tool	Limited CI/CD pipeline features
AutoRABIT	SF DevOps	Full DevOps suite, backup/restore	Complex setup, learning curve
Azure DevOps	General CI/CD	Enterprise integration, boards/repos	Requires custom SF pipeline
GitLab CI	General CI/CD	Integrated repo + CI/CD, self-hosted option	Requires custom SF pipeline

CI/CD Pipeline Architecture

Figure 5. Each environment gate (SIT integration tests, UAT sign-off, staging smoke tests) catches a different failure class. Collapsing these gates to speed delivery transfers that risk directly to production.

Deployment Strategies

Big Bang vs Phased Deployment

Strategy	When to Use	Risk Level
Big Bang	Small changes, low risk	Low-Medium
Phased by Feature	Multiple features, independent	Medium
Phased by User Group	Pilot → rollout	Low
Blue-Green	Zero downtime required	Medium (complex setup)

Destructive Changes

Deleting metadata requires special handling in Salesforce:

• Destructive changes manifest: XML file listing components to delete
• Pre-destructive vs post-destructive: Pre runs before deployment, post runs after
• Cannot delete components referenced by other deployed components
• Package versions: Removing components from a package version is not straightforward

Destructive Change Risks

Destructive changes cannot be easily rolled back. Always deploy them to a sandbox first. Document every destructive change with a business justification. Include destructive changes in code review; they are often more dangerous than additions.

Feature Flags

Feature flags allow code to reach production without activating it for users:

Implementation options:

• Custom Metadata Type: Store feature flags as metadata records (deployable, no DML needed to check)
• Custom Settings: Hierarchy-based, per-user or per-profile (DML to change, quick to toggle)
• Custom Permissions: Assign via Permission Set (user-level control)

Use cases:

• Deploy integration code before the external system is ready
• Gradual rollout to user groups
• Kill switch for problematic features
• A/B testing of automation behavior

Figure 6. Feature flags decouple deployment from release. Code reaches production inactive, then activates per user group or percentage. Disabling the flag is a seconds-long rollback that requires no redeployment and no CAB emergency approval.

Deployment Checklist

Pre-Deployment

• All tests pass in the source environment
• Code review completed and approved
• Deployment validated (check-only deployment) in target
• Destructive changes documented and reviewed
• Rollback plan documented
• Communication sent to affected users
• Deployment window confirmed (off-peak hours for production)

Post-Deployment

• Smoke tests executed in target environment
• Integration endpoints verified
• Permission assignments confirmed
• Monitoring dashboards checked
• User communication sent (release notes)
• Deployment logged in release management tracker

Related Topics

• Environment Strategy: Where deployments target
• Testing Strategy: What tests run in the pipeline
• Governance Model: Change Advisory Board and release governance
• Decision Guides: CI/CD tool selection and branching strategy flowcharts
• Best Practices: DevOps best practices and anti-patterns
• Declarative vs Programmatic: How solution choices change deployment complexity

Sources

• Salesforce Developer Documentation: Salesforce DX Developer Guide
• Salesforce Architects: Release Management
• Salesforce Developer Documentation: Unlocked Packages
• Salesforce Help: Change Sets
• Atlassian: GitFlow Workflow
• Martin Fowler: Feature Toggles
• Salesforce Developer Documentation: Package Version Numbering Guidance
• Salesforce Developer Documentation: Unlocked Package Best Practices
• Salesforce Trailhead: DevOps Center Quick Look
• Salesforce Developer Documentation: Continuous Integration
• Salesforce: Move from sfdx (v7) to sf (v2)
• Salesforce: Mapping sfdx Commands to Their sf Equivalents
• Salesforce Developers Blog: Supercharge DevOps with Built-In Testing and Quality Gates
• Salesforce: Agentforce Testing Center Announcement
• CTA Study Groups: Community CI/CD pipeline patterns for Salesforce