Moving Salesforce delivery from change sets to CI/CD

Change sets package metadata through Salesforce Setup and move it between related orgs. They are familiar, but they give limited help with line-by-line review, version history, repeatable validation and proving that the approved change is the one released.

CI/CD improves those controls only when the repository represents the real org, developers use it for every change, and production deployment follows one approved path. A pipeline alongside continued untracked Setup changes creates a second source of confusion rather than solving the first.

Agree the operating model

• Which Salesforce org or environment is used for each stage of delivery.
• Which metadata is owned by the repository and which configuration or data remains outside it.
• Who can approve, deploy and perform emergency production work.
• How support cases, project requirements, branches and releases are linked.
• What evidence is required before production and where it is retained.

Create and reconcile the metadata baseline

Start with a Salesforce DX project and retrieve the in-scope metadata from the org that represents the current baseline. Commit that snapshot, then compare it with any existing repository and investigate differences before accepting either side as current.

• Build a package manifest for the metadata types the team intends to manage.
• Retrieve from an explicitly named org and record its organisation ID or domain.
• Separate generated noise from meaningful metadata without hiding real changes.
• Document components that cannot be retrieved or deployed through the chosen API route.
• Back up production metadata before the first pipeline-led release.

Do not treat a successful retrieve as proof that the repository is complete. Some changes depend on data, feature settings, managed packages, certificates, credentials or manual configuration that require a separate release step.

Make Git the working path

1. Start each change from a requirement or issue with acceptance criteria.
2. Create a short-lived branch from the current release baseline.
3. Build in an appropriate sandbox, scratch org or local source-driven workflow.
4. Retrieve only intentional org-side changes and inspect the diff.
5. Open a pull request that explains the behaviour, metadata and test approach.
6. Merge only after review and the required Salesforce validation succeeds.

Begin with a contained field, layout, permission or Apex change that has clear tests and no unrelated production dependency. The organisation's most complex release is a poor way to prove a new process.

Add target-aware validation

Salesforce CLI supports validation without committing the metadata change. The correct command and test level depend on whether the target is production or a sandbox and on the contents of the deployment. Keep the target alias explicit and confirm what it resolves to before running either example.

# Production validation with tests
sf project deploy validate \
  --source-dir force-app \
  --target-org production \
  --test-level RunLocalTests

# Sandbox dry run with tests
sf project deploy start \
  --dry-run \
  --source-dir force-app \
  --target-org uat \
  --test-level RunLocalTests

• Run fast local checks before consuming time in a Salesforce validation job.
• Select tests around the changed behaviour and its shared dependencies.
• Publish the deployment ID and concise results with the pull request.
• Do not use ignore flags as a routine way to turn Salesforce warnings into successful builds.
• Revalidate when the metadata, target baseline or release payload changes materially.

Control the production release

A successful validation is evidence, not approval. Keep production secrets in a protected environment, require the agreed reviewer or release owner, and deploy the same commit and payload that passed review. Capture the final deployment result against the issue or release.

• Make destructive changes visible and separately approved.
• List pre-deployment, data, configuration and post-deployment steps in order.
• Define the user checks that confirm the change works after release.
• Prefer a tested forward fix for recovery; metadata rollback can itself be a risky deployment.
• Keep the previous source version and relevant org backup available for diagnosis.

Set the change-set cutover

Use a short, planned transition with deletion criteria. Change sets can be retired when the in-scope metadata baseline is reconciled, the team can build and review through Git, target-org authentication works, required validation runs reliably, and the first production release has been verified.

After cutover, an emergency org-side change should be retrieved, reviewed and committed immediately through the same canonical path. It should not become a reason to keep a permanent manual release route alive.

Measure whether the process is helping

• Can a reviewer understand what changed without reconstructing it in Setup?
• Can the team reproduce a validation from the recorded commit and target?
• Are deployment failures found before the production window?
• Can an operations owner trace a released change back to the original request?
• Has untracked production metadata reduced rather than moved somewhere else?

Connecting scope, review, testing and production state gives small support changes and larger project releases a clearer, less stressful route into production.