When developers who have shipped normal software hit Salesforce for the first time, the deployment story is what surprises them most. In a typical stack you write code, build an artifact, and push it to a server. On Salesforce there is no artifact and no server you control. The application exists as metadata inside an org, a live Salesforce instance, and a "change" can be anything from an Apex class to a validation rule an admin created by clicking through the UI. Getting those changes from a sandbox into production, reliably and repeatably, turns out to be hard enough that Salesforce CI/CD became a specialism with a whole category of tools built for it.
This is worth understanding before choosing any tool, because the tool decision only makes sense once you see why the problem is different. So this piece covers two things: why Salesforce deployment is its own discipline, and how to choose the tooling once you accept that it is.
Why Salesforce deployment is not like deploying an app
The core difference is that the "app" is metadata living inside an org, not a binary you build and copy. Your changes span two worlds at once: code (Apex, Lightning Web Components, triggers) and configuration (objects, fields, Flows, validation rules, page layouts, permission sets). Some of those changes come from developers writing code, and some come from admins clicking through setup, and both have to travel together from a sandbox, a copy of production used for development, into production itself.
That combination is what makes it hard. Click-made config and code-made changes both have to be captured and moved, and historically moving metadata between orgs was genuinely painful. The native mechanism for years was the Change Set: you manually clicked together a list of components, uploaded them to a related org, and deployed, with no version history, no rollback, and a real risk of leaving out a dependency. Doing that by hand, release after release, across several environments, does not scale, and that pain is exactly why dedicated Salesforce DevOps tooling exists. Treating Salesforce deployment as if it were normal software, or as if Change Sets were good enough, is the first mistake teams make.
The model that makes it sane: source-driven with Git
The shift that turns Salesforce deployment from a manual chore into an engineering practice is going source-driven, with Git as the source of truth. The mental model takes a moment to click because the metadata starts out living in the org, not in files.
You begin by retrieving the metadata out of an org into files. Salesforce represents configuration and code as metadata files, and the Salesforce CLI (or a tool like Gearset or DevOps Center) pulls them from the org into a local project that you commit to Git. The usual starting point is to take production as the baseline, the first commit, so Git now holds a faithful snapshot of what is live. From that moment the direction of truth flips: instead of the org being the source, Git becomes the source, and changes flow from Git into the orgs.
In day-to-day work, each environment is mapped to a branch. A dev branch tracks the dev sandbox, an integration branch the QA sandbox, a UAT branch the staging org, and main tracks production. A single change then follows a path that any developer will recognise: branch off integration, make the change in the dev sandbox (clicks and code both), retrieve the changed metadata and commit it, open a pull request into integration where the code gets reviewed, let CI deploy that branch to the QA org and run the Apex tests, then promote up through UAT and finally to production behind an approval gate. The only two genuinely Salesforce-specific parts are that "code" means metadata retrieved from an org, and "deploy" means applying that metadata to the target org through the Metadata API so the org matches the branch, rather than copying a binary to a server. Everything else is ordinary Git discipline, which is the point: source-driven is how Salesforce deployment becomes reviewable, repeatable, and recoverable.
The tooling ladder, from Change Sets to paid platforms
Once you are source-driven, the question is what applies the metadata for you, and there is a clear ladder from manual to fully managed.
At the bottom are Change Sets: native, manual, no Git, no version control, no rollback, and only between related orgs. They are where teams start and where they should not stay. One rung up is the Salesforce CLI plus the Metadata API, the command-line foundation that everything else is built on; you can script your own pipeline on it with a generic CI engine like GitHub Actions, Azure DevOps, Jenkins, or GitLab CI, which drive the CLI without being Salesforce-specific. Then there is DevOps Center, which is free and native and a genuine step up from Change Sets: it is source-driven through a UI so you do not need to be fluent in the CLI, it connects to GitHub, it tracks which metadata changed, and it promotes work items through a pipeline with review. It is far better than Change Sets, and it is weaker than the paid tools on rollback, CI automation, data deployment, and integrations.
Above the free options sit the paid platforms, and the honest way to tell them apart is by what each one optimises for. Gearset is external SaaS with the best developer experience: fast to adopt, strong diff, snapshot-based rollback, solid CI, and the ability to deploy and back up data, which makes it the best cost-to-benefit choice for most development teams that want power without heaviness. Copado is native and is a full ALM platform covering planning through release in one place, with deep Salesforce integration and governance, at the cost of being heavy, complex, expensive, and usually needing a real implementation; it fits large enterprises with many teams and complex releases. AutoRABIT leans into compliance, governance, and backup and recovery, which makes it a fit for regulated industries like finance and healthcare that need auditability and disaster recovery alongside CI/CD. Flosum is 100% native so data never leaves Salesforce, which is its whole reason to exist for security-first organisations with strict data-residency requirements, accepting less Git flexibility in return.
Choosing the tool by the constraint that actually binds you
The mistake in tool selection is comparing feature lists. The better approach is to identify the one constraint that actually binds your situation and let it choose, because these tools are pitched at genuinely different needs rather than competing on the same axis.
If your binding constraint is developer speed and clean rollback, and you do not need heavyweight end-to-end ALM, Gearset is usually the answer and the best value. If it is coordinating many teams across a complex release process and you want one platform for the whole lifecycle with the budget and appetite to implement it, that is Copado. If it is regulatory compliance, governance, and recoverability in a regulated industry, that is AutoRABIT. And if it is an absolute requirement that data never leaves the Salesforce platform, that is Flosum. For a smaller regulated client, say a lean asset manager, this often resolves cleanly: the binding constraint is compliance and data control rather than scale, which points away from the heavyweight enterprise ALM and toward whichever tool meets the data and audit requirement most directly without the implementation burden.
One nuance worth carrying into any of these: rollback on Salesforce is not the clean revert you get with a binary deploy. Reverting metadata is not always symmetric, some changes are not cleanly reversible, and data changes do not roll back with metadata at all, so "we can just roll back" deserves scrutiny rather than assumption when you evaluate a tool's recovery story.
Where to start
If you are still on Change Sets, the move is not to jump straight to an enterprise platform; it is to get source-driven first. Stand up Git with production as the baseline, map environments to branches, and adopt DevOps Center or a CLI-plus-CI pipeline so that deployment becomes reviewable and repeatable. Only once that foundation is in place does the paid-tool decision become meaningful, and at that point you choose by the single constraint that binds you rather than by the longest feature list. Salesforce CI/CD is its own discipline precisely because the platform is different; the teams that treat it that way ship calmly, and the teams that treat it like Change Sets or like normal software keep paying for it at every release.
Setting up Salesforce CI/CD or moving off Change Sets? Sapota's Salesforce team builds source-driven Git pipelines and selects the right deployment tooling on production engagements. Get in touch ->
See our full platform services for the stack we cover.
