Salesforce deployment tooling has evolved from the change set era (admin-driven, in-org clicky) through Ant / Metadata API (developer-driven, scripted) to Salesforce DX (source-driven, Git-backed) and finally commercial DevOps platforms layered on top. A modern team usually mixes two or three of these.
Native tools
Change Sets
The original. UI-driven, no install required, runs entirely inside Salesforce.
- Outbound change set in the source sandbox lists the components to send.
- A Deployment Connection between the two orgs authorises the transfer.
- The change set lands as an inbound change set in the target. The target admin clicks Deploy.
Pros: zero install, admin-friendly. Cons: no version control, no diff, no automation, brittle for medium-sized teams.
Salesforce DX / Salesforce CLI (sf)
The modern answer. Metadata lives in Git as a folder structure (force-app/main/default/). The CLI deploys directly:
sf project deploy start --source-dir force-app/main/default --target-org production
sf project deploy validate --source-dir force-app --target-org production
sf project deploy quick --job-id 0Af...Pros: source-of-truth in Git, scriptable, scratch orgs for source-driven dev, peer-reviewable diffs. Cons: learning curve, requires Git and Node.js, harder for non-dev admins.
Workbench
workbench.developerforce.com. Free web tool. Deploy from a package.xml + zipped source without installing anything. Excellent for quick fixes and emergency deploys.
Ant Migration Tool
Java + Apache Ant + Metadata API. The legacy CI workflow. Still used in long-running enterprise pipelines that haven’t migrated to sf. Slower than DX, but rock-solid and battle-tested.
<target name="deploy">
<sf:deploy username="${sf.username}"
password="${sf.password}"
serverurl="${sf.serverurl}"
deployRoot="src"
runTests="MyTest" />
</target>Metadata API directly
Behind every tool above is the Metadata API — SOAP and REST endpoints for retrieving and deploying metadata. You can call it directly from any language; tools like the CLI and Workbench just wrap it nicely.
Packaging tools
Unlocked Packages (2GP)
Modern, Git-driven, version-controlled packages. Build with sf package version create, install with sf package install. Used inside organisations for internal modularisation.
Managed Packages (2GP)
The same mechanism, but produces a sealed, namespaced artifact. Used by AppExchange ISVs.
First-generation Packages (1GP)
Legacy unmanaged / managed packages built from a “packaging org”. Still common; new projects should pick 2GP.
Commercial DevOps platforms
These wrap CLI / Metadata API in CI/CD workflows, branching strategies, and approval gates:
- Copado — Salesforce-native, deep flow / approval / quality gates.
- Gearset — diff-and-deploy UX, very popular for admin-led teams.
- Flosum — Salesforce-native, regulated-industry focus.
- AutoRABIT — enterprise CI/CD with strong testing.
- Salto — config-as-code with rich diff.
- Hutte — modern source-driven dev for Salesforce.
- Prodly — config + data deployment in one.
- Blue Canvas — Git-first deployment.
Which to pick
| Situation | Tool |
|---|---|
| Quick one-off, two orgs, simple change | Change set |
| Solo developer, source-driven, Git | Salesforce CLI |
| Two-person team building a small product | Salesforce CLI + GitHub Actions |
| Enterprise with 10+ devs, regulated industry | Commercial (Copado / Flosum / Gearset) |
| Emergency hotfix, no time for pipeline | Workbench |
| Distributing internally to multiple orgs | Unlocked packages (2GP) |
| Distributing as a paid AppExchange product | Managed package (2GP) |
| Legacy ant scripts already in place | Ant Migration Tool |
Interview tip
Show breadth: name change sets, Salesforce CLI, packages, and one commercial tool (Gearset, Copado, or Flosum). Explain when each one fits. That demonstrates you’ve moved beyond “I know change sets” and understand the modern landscape.
Verified against: Salesforce DX Developer Guide, Metadata API Developer Guide, ISVforce Guide — Packaging. Last reviewed 2026-05-17 for Spring ‘26 release.