CI/CD for Salesforce: The Intro Nobody Gives You Before Session 90

If you've been following along since scratch orgs and source tracking, you already have most of what CI/CD needs. This session doesn't introduce a new way of thinking — it introduces the automation that sits on top of what you already know. CI/CD is not a separate DevOps skill you bolt onto Salesforce development. It's the logical next step once your metadata lives in Git and your orgs are disposable and source-driven.

What CI/CD actually stands for

CI is Continuous Integration — every time someone pushes a change, it gets automatically merged, validated, and tested against the rest of the codebase, instead of sitting in isolation until a big, risky integration day. CD is Continuous Delivery (or Continuous Deployment) — once a change passes CI, it's automatically prepared for release, and in the "Deployment" version, actually released, without a person manually pushing it through Setup.

Put together: commit a change, and a pipeline picks it up, checks it, tests it, and moves it toward production — the same sequence, every single time, whether it's a Friday afternoon or 3am.

Why this depends on source-driven development

A CI/CD pipeline needs something concrete to act on. It checks out your metadata from a Git repository, deploys it into a fresh environment, and validates it. If your org's configuration only exists by clicking through Setup — nothing in version control — there is nothing for a pipeline to check out. This is exactly why scratch orgs and source tracking came before this session: they're the prerequisite, not a separate topic.

Once metadata lives in Git as the single source of truth, a pipeline can treat every commit the same way a scratch org treats a definition file — build it, validate it, and let go of it if it doesn't hold up.

Why manual deployment stops scaling

Manual deployment works fine with one developer and a small org. It breaks down as both grow, for reasons that show up quietly at first:

• Change sets miss dependencies — a flow references a field nobody remembered to include, and the deployment fails in production, not before.
• Testing becomes optional under deadline pressure. Nobody runs the full Apex test suite by hand every time; someone eventually skips it "just this once."
• Deployment becomes an event, not a routine. When deploying is rare and manual, every deployment is higher stakes than it needs to be — which makes teams deploy less often, which makes each deployment bigger and riskier. The exact opposite of what you want.

Popular tools — a conceptual overview

At this intro level, you don't need to master any of these. You need to know what they're for and roughly where each one fits:

GitHub Actions — CI/CD built directly into GitHub. You write a YAML workflow file that runs whenever code is pushed, using the Salesforce CLI to validate and deploy. Lowest friction if your repo already lives on GitHub.

CircleCI — a dedicated CI/CD platform that works with any Git host. Similar YAML-based configuration to GitHub Actions, popular with teams that want a CI tool decoupled from where their code is hosted.

Copado — a release management platform built specifically for Salesforce. Instead of hand-writing pipeline scripts, you configure environments, promotion paths, and approval gates through a UI designed around Salesforce's release process. Aimed at teams that want structured governance on top of the pipeline.

Gearset — another Salesforce-native CI/CD and deployment tool, known for comparing org metadata, automating deployments between environments, and catching configuration drift. Often the first paid tool teams adopt once a bare-bones script stops being enough.

None of these are "the right answer" in isolation — GitHub Actions and CircleCI are closer to the metal and require you to build the pipeline logic yourself; Copado and Gearset trade some of that flexibility for structure and a smaller learning curve specific to Salesforce releases.

A basic pipeline, in words

Strip away the tool-specific syntax and almost every Salesforce CI/CD pipeline follows the same four stages:

• Lint — check the code and metadata for obvious problems (formatting, unused variables, missing sharing declarations) before spending any time on a full deployment.
• Validate — perform a check-only deployment against a target org (often a fresh scratch org, echoing what you already know) to confirm the metadata is deployable without actually committing it.
• Deploy — if validation passes, deploy the metadata for real, into a sandbox, staging org, or production, depending on which branch or environment triggered the pipeline.
• Test — run the Apex test suite against the deployed metadata, and fail the pipeline loudly if coverage or test results don't meet the bar, instead of finding out from a user weeks later.

Lint catches the cheap mistakes early. Validate confirms the change is structurally sound. Deploy actually moves it. Test proves it works. Each stage only runs if the one before it passed — so a broken change never reaches production having skipped a step.

Why this matters before going deeper

Everything after this session — branching strategies, environment promotion, approval gates, rollback plans — builds on top of these four stages and the assumption that your metadata is already source-driven. Understanding the shape of a basic pipeline now means the next sessions add detail to a picture you already have, instead of introducing an entirely new mental model halfway through.

You don't need to set up a pipeline today. You need to recognize what one is doing when you see it — and know that "lint, validate, deploy, test" is the skeleton every more sophisticated setup is built on top of.