Deployment & DevOps #3 of 12 Strong

Salesforce DevOps Center

DevOps Center is Salesforce's native DevOps tool, included free with all orgs. It provides git integration, work item tracking, and basic CI/CD pipelines. The UI is simple and the tool is designed for teams just starting with version control. It does not include backup or advanced diffing.

Why it ranks here

  • Free and native means no procurement or security review; every org already has it.
  • Git-based workflows with GitHub or Bitbucket integration make version control accessible.
  • Work item tracking ties metadata changes to user stories, improving traceability.

Where it sits

  • DevOps Center is simpler and less feature-rich than Gearset or Copado but costs nothing.
  • Compare and conflict resolution are basic; manual merge conflicts are common.
  • No backup or rollback features; you need a separate tool for disaster recovery.

How GTM Systems teams use it

  • Per sprint: commit metadata changes to git branches and link them to work items.
  • Weekly: promote changes from dev to QA sandboxes using built-in pipelines.
  • Daily: review commit history to see who changed what and when.
  • Ad-hoc: deploy hotfixes to production via manual promotion rather than automated CI/CD.

In-depth notes

  • Free with all Salesforce orgs; no license cost.
  • Git integration is source-driven but limited to GitHub and Bitbucket; GitLab is not supported.
  • No backup, no automated testing, no advanced diffing; this is a version control tool, not a full DevOps platform.
  • Work item tracking is lightweight; it does not replace Jira or Azure DevOps.
  • DevOps Center is a good starting point but most teams outgrow it within 6-12 months.

Best for

Small teams just starting with version control who want a free, native solution.

Avoid if

You need backup, advanced compare, or automated testing (use Gearset or Copado).

Learning guide

Beginner Time to value: First commit in 30-60 minutes

Setup

Enable DevOps Center in Setup, connect GitHub or Bitbucket repo, create first work item, and commit a field change to see the basics.

First thing to build

Create a work item for a feature, commit changes to a feature branch, then promote from dev sandbox to QA sandbox via the UI.

What actually matters

  • Branch per work item for isolated changes
  • Manual promotion between sandboxes (no automated CI/CD)
  • Basic conflict resolution via UI
  • Work item tracking tied to commits

Watch out

DevOps Center does not validate deployments before promotion, so conflicts appear during deployment rather than before.