CI/CD & Deployment Strategy

Continuous Integration and Continuous Deployment (CI/CD) in Salesforce is fundamentally different from traditional software CI/CD. The platform’s metadata-driven architecture, shared sandbox environments, and org-based development model create unique challenges. A CTA must design a deployment strategy that balances automation, safety, and team velocity.

Git Branching Strategies

GitFlow vs Trunk-Based Development

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

flowchart LR
    subgraph GitFlow
        direction TB
        GF_MAIN[main] --> GF_DEV[develop]
        GF_DEV --> GF_FEAT1[feature/cpq-pricing]
        GF_DEV --> GF_FEAT2[feature/case-routing]
        GF_DEV --> GF_REL[release/2024-Q4]
        GF_REL --> GF_MAIN
        GF_MAIN --> GF_HOT[hotfix/email-bug]
        GF_HOT --> GF_MAIN
    end

    subgraph Trunk-Based
        direction TB
        TB_MAIN[main] --> TB_FEAT1[feature/cpq-pricing]
        TB_MAIN --> TB_FEAT2[feature/case-routing]
        TB_FEAT1 --> TB_MAIN
        TB_FEAT2 --> TB_MAIN
    end

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. The Salesforce metadata model 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 / sfdx) is the foundation of modern Salesforce DevOps.

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). Better for version control, meaningful diffs.
• 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 offers multiple ways to move metadata between orgs. The right choice depends on team maturity, org complexity, and governance needs.

flowchart TD
    subgraph Legacy["Legacy"]
        CS[Change Sets<br/>Manual, no rollback<br/>no version history]
    end

    subgraph Modern["Modern — CLI-Based"]
        CLI[Salesforce CLI<br/>sf project deploy<br/>Source or metadata format]
        PKG[Unlocked Packages<br/>Versioned artifacts<br/>Dependency management]
    end

    subgraph Platform["Platform-Native"]
        DOC[DevOps Center<br/>Click-based + Git<br/>Built-in tracking]
    end

    subgraph ThirdParty["Third-Party Tools"]
        COP[Copado<br/>SF-native DevOps<br/>Compliance tracking]
        GS[Gearset<br/>Smart diff/merge<br/>Comparison tools]
    end

    CS -->|"Migrate to"| CLI
    CS -->|"Migrate to"| DOC
    CLI -->|"Evolve to"| PKG
    DOC -->|"Integrates with"| CLI

    style CS fill:#e76f51,stroke:#c45a3f,color:#fff
    style CLI fill:#2d6a4f,stroke:#1b4332,color:#fff
    style PKG fill:#2d6a4f,stroke:#1b4332,color:#fff
    style DOC fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style COP fill:#f4a261,stroke:#d4823e,color:#000
    style GS fill:#f4a261,stroke:#d4823e,color:#000

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

DevOps Center is Salesforce’s platform-native approach to change management. It provides a UI layer over Git-based source control, making it accessible to admins who are not comfortable with CLI tools. It supports both declarative and programmatic developers working together on the same project. However, it does not replace the need for a full CI/CD pipeline for complex enterprise implementations.

Change Sets: When They Are Still OK

Change sets are the legacy deployment mechanism. In a CTA scenario, you may encounter orgs still using 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 to modern DevOps — but do not propose ripping out change sets overnight.

Unlocked Packages

Unlocked packages are Salesforce’s recommended approach for organizing and deploying metadata in large-scale 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

flowchart TD
    subgraph Core["Core Package (Base)"]
        A[Custom Objects]
        B[Custom Fields]
        C[Permission Sets]
    end

    subgraph Sales["Sales Package"]
        D[Sales Flows]
        E[Sales LWC]
        F[Sales Apex]
    end

    subgraph Service["Service Package"]
        G[Service Flows]
        H[Service LWC]
        I[Service Apex]
    end

    subgraph Integration["Integration Package"]
        J[Named Credentials]
        K[External Services]
        L[Integration Apex]
    end

    Sales --> Core
    Service --> Core
    Integration --> Core

    style Core fill:#1a535c,stroke:#0d3b44,color:#fff
    style Sales fill:#2d6a4f,stroke:#1b4332,color:#fff
    style Service fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style Integration fill:#f4a261,stroke:#d4823e,color:#000

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.

flowchart TD
    subgraph Versions["Package Versions (Install Order)"]
        direction TB
        CORE_V["core-package<br/>v2.5.0 (promoted)"]
        SALES_V["sales-package<br/>v1.8.0 (promoted)<br/>depends: core >= 2.4"]
        SVC_V["service-package<br/>v1.3.0 (promoted)<br/>depends: core >= 2.5"]
        INT_V["integration-package<br/>v1.1.0 (promoted)<br/>depends: core >= 2.3"]
        ANALYTICS_V["analytics-package<br/>v0.9.0 (beta)<br/>depends: core >= 2.5<br/>+ sales >= 1.7"]
    end

    CORE_V --> SALES_V
    CORE_V --> SVC_V
    CORE_V --> INT_V
    CORE_V --> ANALYTICS_V
    SALES_V --> ANALYTICS_V

    subgraph Pipeline["CI/CD Build Order"]
        direction LR
        B1[1. Build Core] --> B2[2. Build Integration]
        B2 --> B3[3. Build Sales]
        B3 --> B4[4. Build Service]
        B4 --> B5[5. Build Analytics]
    end

    style CORE_V fill:#1a535c,stroke:#0d3b44,color:#fff
    style SALES_V fill:#2d6a4f,stroke:#1b4332,color:#fff
    style SVC_V fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style INT_V fill:#f4a261,stroke:#d4823e,color:#000
    style ANALYTICS_V fill:#e76f51,stroke:#c45a3f,color:#fff

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 — you cannot modify it. 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

flowchart LR
    A[Developer<br/>Commits Code] --> B[Git Repository<br/>Feature Branch]
    B --> C{Pull Request<br/>Created}
    C --> D[Automated Checks]

    subgraph Pipeline["CI/CD Pipeline"]
        D --> E[Create Scratch Org]
        E --> F[Deploy Source]
        F --> G[Run Apex Tests]
        G --> H[Run LWC Tests]
        H --> I[Static Analysis<br/>PMD/ESLint]
        I --> J{All Checks<br/>Pass?}
    end

    J -->|No| K[Notify Developer<br/>Fix Issues]
    J -->|Yes| L[Code Review<br/>Approved]
    L --> M[Merge to Develop]
    M --> N[Deploy to SIT]
    N --> O[Integration Tests]
    O --> P[Deploy to UAT]
    P --> Q[UAT Sign-off]
    Q --> R[Deploy to Staging]
    R --> S[Smoke Tests]
    S --> T[Deploy to Production]

    K --> A

    style A fill:#2d6a4f,stroke:#1b4332,color:#fff
    style T fill:#e76f51,stroke:#c45a3f,color:#fff
    style J fill:#f4a261,stroke:#d4823e,color:#000

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

Destructive changes (deleting metadata) require 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: Deleting components from a package version is not straightforward

Destructive Change Risks

Destructive changes cannot be easily rolled back. Always deploy destructive changes 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 deploying code to 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

flowchart TD
    A[Feature Code Deployed] --> B{Feature Flag<br/>Enabled?}
    B -->|Yes| C[Execute New Logic]
    B -->|No| D[Execute Legacy Logic]
    C --> E[Monitor Performance]
    E --> F{Issues Detected?}
    F -->|Yes| G[Disable Feature Flag]
    G --> D
    F -->|No| H[Full Rollout]
    H --> I[Remove Feature Flag<br/>and Legacy Code]

    style G fill:#e76f51,stroke:#c45a3f,color:#fff
    style H fill:#2d6a4f,stroke:#1b4332,color:#fff

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 affect 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
• CTA Study Groups: Community CI/CD pipeline patterns for Salesforce