Salesforce Deployment Strategies: Change Sets vs CLI vs Packages

Change sets are fine until the project involves three developers, a release manager, and a deadline that matters. At that point they become a liability — manual, slow, with no version history and no way to see what changed since the last deployment. Most Salesforce teams learn this the hard way. Here is what your options actually are.

The four approaches

Change sets are point-and-click and built into every org. You build a set of components in a sandbox, upload it to your organisation's deployment container, and pull it into the target environment. The upside: no tools, no setup. The downside: they are one-way (you cannot diff against what's in production), they have no branching concept, and they fail in ways that are hard to diagnose. Use them for solo developers or for teams that deploy infrequently.

Salesforce CLI (SF CLI) is the command-line tooling Salesforce ships for source-driven development. You work in source format in a Git repository, push to scratch orgs or sandboxes using sf project deploy start, and pull back with sf project retrieve start. This is the tool that serious teams use. It integrates with any CI/CD system, gives you a full deployment history through Git, and makes code reviews possible. The setup investment is real — you need VS Code or similar, the extension pack, and someone who is comfortable with a terminal.

Packages — managed and unmanaged — are for distributing metadata across unrelated orgs, not for your internal sandbox-to-production workflow. Managed packages are what AppExchange vendors ship; they are versioned, locked, and upgradeable. Unmanaged packages expose all code and are occasionally used for templates or proof-of-concept sharing. If you are deploying between your own environments, neither package type is the right tool.

DevOps Center is Salesforce's native pipeline UI, released GA in 2023. It wraps the CLI in a point-and-click interface, connects to a Git repository, and lets admins move work items through pipeline stages without touching a terminal. It is a reasonable middle ground for teams with mixed technical ability. If your team is already comfortable with Git and the CLI, a dedicated DevOps platform (Copado, Gearset, Flosum) gives you more pipeline control, better rollback options, and stronger test orchestration.

What actually goes wrong

Profiles are the most common deployment problem, across every method. They capture every field-level security setting, page layout assignment, and tab visibility in your org. In source format, Profile files are enormous and diff poorly. In change sets, they often overwrite settings you wanted to keep. The standard advice is to avoid deploying Profiles entirely and use Permission Sets instead — which Salesforce themselves now recommend.

Flows with active versions require careful handling. You cannot deploy a new version of a flow over an active version without first deactivating it, which breaks anything currently running. Schedule this during a maintenance window and test the deactivation sequence in a Full Sandbox first.

The deployment order matters for dependent metadata. If you deploy an Apex class that references a custom object field that does not exist in the target org yet, it fails. Change sets handle this partially with dependency checking. CLI deployments require you to think through the sequence yourself or deploy everything at once.

How to choose

One developer, one sandbox: change sets. The overhead of CLI setup is not worth it at this scale.

Two or more developers committing simultaneously: CLI with Git, immediately. Change sets cannot handle parallel work. You will lose metadata and cause conflicts trying to merge two change sets that touched the same component.

Non-technical admins who need to move work through a pipeline: DevOps Center. It removes the terminal but keeps the Git history and audit trail.

Complex release cadences, multiple release streams, or regulated environments: a proper DevOps platform. The Salesforce-native tooling does not do blue/green deployments, does not handle rollback automatically, and does not give you fine-grained test orchestration.

Before you deploy to production

Test in a Full Sandbox, not a Partial or Developer sandbox. Full Sandboxes have production-sized data and the same configuration as your live org. A deployment that passes in a Developer sandbox can fail in production because a validation rule references data that only exists in production volumes.

Run all Apex tests as part of the deployment, not before it. Salesforce requires 75% code coverage for production deployments and will enforce it. Running tests separately and then deploying does not satisfy the requirement.

The single thing that causes the most deployment incidents is not the tooling — it is deploying without a rollback plan. Before every significant release, know exactly what you will do if the deployment fails or causes unexpected behaviour. That answer cannot be "we'll figure it out."