How to Build a Salesforce Continuous Integration Pipeline

Salesforce CI/CD is a pipeline that commits every change to version control, validates it against a target org, runs Apex tests and promotes it to production. Within it, Salesforce continuous integration catches conflicts early, and continuous delivery or deployment moves the validated metadata from sandbox to production without change sets.

CI/CD is one part of Salesforce DevOps. It's harder on Salesforce than on most platforms, because much of what changes is admin-built metadata rather than code.

What Is CI/CD in Salesforce DevOps?

At the broadest level sits Salesforce DevOps: the culture, processes and tooling a team uses to plan, build, test and release changes to an org. Continuous integration, continuous delivery and continuous deployment are practices inside that discipline, and a CI/CD pipeline is the automation that carries them out.

That automation counts for more in Salesforce development because of how much complexity teams manage. In the 2024 SF Ben Developer Survey, 53% of Salesforce developers agreed that the platform is becoming increasingly complex to work with.

Another 34% were neutral, and only 13% disagreed. Automating the build, test and release steps tackles slow development and recurring bugs, with faster merging, fewer overwrites and easier branch management.

Three practices make up a Salesforce CI/CD pipeline. This table shows what each one automates, where it stops and what it looks like in Salesforce.

How CI works on Salesforce

Continuous Integration (CI) merges each change into a shared repository frequently, then validates it automatically. In Salesforce development, most of that change is XML metadata such as profiles, flows and validation rules.

Admins build much of it rather than developers, so CI on Salesforce rests on three things:

First, version control has to capture declarative work as well as programmatic work. If an admin changes a validation rule directly in Setup and it never reaches a branch, the next deployment silently overwrites it.

Second, validation replaces compilation, and a validation-only deployment is the closest thing to a build step. It runs the full deployment against a target org and reports what would happen without committing anything.

Third, deploying Apex to production requires at least 75% code coverage org-wide, so test execution is a gate you can't opt out of. Catching issues this early means problems become small, same-day fixes instead of release-week emergencies.

Continuous delivery and continuous deployment

Continuous delivery picks up after CI and moves tested changes through sandbox environments, where UAT and integration tests catch problems before release. Under continuous deployment, each verified change then goes on to production with no manual gate.

Six Stages of a CI/CD Pipeline, From Version Control to Rollback

Every pipeline shares the same six stages in the same order, whatever tool runs it. Each stage exists to catch a class of failure the previous stage can't.

Source control comes first, then automated testing on each commit or pull request, covering Apex unit tests and, more and more, static code analysis. Validation is the stage Salesforce teams can't skip, because it runs the real deployment against the real target environment without committing it.

Deployment promotes the validated change, and gating production behind an approval, as in these release management best practices, is the safer default. Monitoring then watches error rates, failed jobs and user reports in the hours after release.

Rollback is the stage teams skip until the first time they need it. Nothing in Salesforce versions your org for you, and redeploying a previous commit only reverts metadata, not the data that referenced the new schema.

Any real rollback plan depends on a pre-deployment backup snapshot you can restore from. Six stages, and the failure each one catches, are summed up in the table below.

Each stage assumes the one before it worked, so a pipeline without validation fails at deployment and one without rollback fails at recovery. Our guide to CI/CD pipelines that hold up under real release pressure covers what tends to break in production.

Underneath the stages sit five CI/CD components: version control, branching, automated testing, monitoring loops and deployment automation (in place of manual deployments through change sets). Get them right and you improve collaboration and code quality, since version control lets developers work on several features at once without merge conflicts.

How to Build a CI/CD Pipeline in Salesforce with Flosum

Salesforce has no build artifact in the usual sense. The pipeline moves metadata between long-lived Salesforce environments that already hold configuration, data and users, and since they drift apart, generic CI/CD tooling often needs heavy scripting.

Flosum DevOps comes in three deployment options. Salesforce-native runs as a managed package inside your org, Flosum-hosted cloud runs on Flosum's infrastructure, and customer-hosted suits regulated or sovereign environments.

None of them requires Git, since Flosum treats Git as optional, not mandatory. Each Flosum pipeline connects a branch to one or more orgs and sets out the steps for validation, testing and deployment.

Stage #1: Create CI/CD Pipeline in Flosum

Creating it takes three steps, and you add the operations afterward. Open Pipelines from the left sidebar and click Create pipeline, then type a name in the Pipeline name box and click Create pipeline a second time.

Flosum's docs suggest naming each one after its job, for example Release-Branch-Pipeline, and tying it to a stable integration or release branch. Connect only the orgs it actually needs, which reduces unnecessary runs.

Stage #2: Add Pipeline Steps

Each step is one operation with its own settings (Validate, Code Scan or Migrate Data, for instance), and it names the step that runs next when it passes or fails. Adding a step works the same way whichever operation you pick.

1. Open the pipeline on the Pipelines page.
2. Click the + icon between two steps, and give the new step a name.
3. Pick the operation from the Operation dropdown, then choose the target org.
4. On a Validate step, you also pick the Apex test level from the Run tests dropdown.
5. Set On pass and On fail to whichever steps should run next, and click Add.

You don't have to save as you go, because your work saves itself after every change. Flosum's docs add one warning: don't set both On pass and On fail to Stop on any step but the last, or a step with no path to it gets removed.

A Validate step checks the changes without committing anything to the target org. For safer automation, the docs suggest routing its On fail result to a Rollback operation.

Stage #3: Execute a Pipeline

You can run a pipeline from the pipeline editor, from a branch or from the Pipelines page. From the Pipelines page, it takes three steps.

• Go to Pipelines in the left sidebar and open the pipeline.
• Select Run pipeline and pick the branch to run it for.
• Click Run.

Seeing a "Pipeline ran successfully" message only means the job started, not that every step passed. To see the results, open the branch under Code and go to its Activities tab, where each step shows as Completed or Exception with its logs.

Continuous Integration Tools for Salesforce: Build or Buy?

Most teams choose between five broad options, and the right one depends less on features than on who will maintain the CI/CD pipeline.

Everything else builds on Salesforce DX and the Salesforce CLI. Free and scriptable, the sf CLI isn't a CI system by itself: it provides the commands, and you supply the orchestration.

General-purpose CI/CD systems such as GitHub Actions, Azure DevOps or Jenkins give you flexibility and expect you to supply the Salesforce expertise. By contrast, a Salesforce-native DevOps tool supplies that expertise and expects you to work within its model.

Because many of these CI/CD tools are free or open source, assembling your own toolchain can look cheap. License cost is rarely the deciding factor, though, and our build vs buy guide covers the trade-offs in depth.

Paying people to maintain those tools adds up over time. One McKinsey study with the University of Oxford covered more than 5,400 IT projects.

Large ones, with budgets above $15 million, ran on average 45% over budget and 7% over time, while delivering 56% less value than predicted. Most in-house builds are far smaller, but the underlying causes, unclear scope and shifting requirements, scale down just as reliably.

Upkeep never stops either, because Salesforce keeps updating its metadata types and has three major releases a year. Buying moves that burden to the vendor, who tracks metadata and API changes as part of its own release cycle.

Build when the pipeline is a differentiator, and buy when it's infrastructure. Be honest about which one it is for your team.

How to Build a CI/CD Pipeline with GitHub Actions

GitHub Actions is a common way to build a Salesforce CI/CD pipeline without buying a dedicated platform. Its pieces are simple: your metadata lives in a GitHub repository, a workflow file defines what runs and when, and hosted runners execute the Salesforce CLI against your orgs.

Authentication is the step that needs the most care. GitHub runners have no browser, so interactive login is not an option.

Instead, the supported pattern is the OAuth JWT bearer flow. Generate an RSA key pair, upload the certificate to Salesforce, store the private key and consumer key as GitHub encrypted secrets, and authenticate headlessly at the start of each run.

One change to plan for: Salesforce Help says that from Spring '26, new Connected Apps can't be created unless Salesforce Support turns the option on. Existing Connected Apps keep working, but new setups belong on External Client Apps, which also support the JWT bearer flow.

Use the sf CLI (v2), since Salesforce recommends moving from sfdx (v7) to sf (v2). Many tutorials online still use the old commands that begin with sfdx force:.

Workflows are YAML files in .github/workflows, and triggers determine the pipeline's shape. Run validation on pull requests targeting your integration branch, and run deployment on merge to that branch, with a validation-only deployment so nothing is committed until the check passes.

name: Salesforce CI

on:
  pull_request:
    branches: [ integration ]   # validate only
  push:
    branches: [ integration ]   # deploy on merge

jobs:
  salesforce:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0        # full history for delta tooling

      - name: Install Salesforce CLI
        run: npm install --global @salesforce/cli

      - name: Authenticate (JWT bearer flow)
        run: |
          echo "${{ secrets.SF_JWT_KEY }}" > server.key
          sf org login jwt \
            --client-id "${{ secrets.SF_CONSUMER_KEY }}" \
            --jwt-key-file server.key \
            --username "${{ secrets.SF_USERNAME }}" \
            --instance-url "${{ secrets.SF_INSTANCE_URL }}" \
            --alias target-org
          rm -f server.key

      - name: Validate (pull request only)
        if: github.event_name == 'pull_request'
        run: |
          sf project deploy start \
            --target-org target-org \
            --dry-run \
            --test-level RunLocalTests \
            --wait 60

      - name: Deploy (merge only)
        if: github.event_name == 'push'
        run: |
          sf project deploy start \
            --target-org target-org \
            --test-level RunLocalTests \
            --wait 60

Two practices save a lot of debugging time. Set fetch-depth: 0 on the checkout step, because the checkout fetches a single commit by default and delta deployment tools need full git history to calculate a diff.

Also prefer RunLocalTests over RunAllTestsInOrg, which per the Salesforce CLI reference also runs managed package tests and slows every run for no benefit. Set up this way, GitHub Actions gives you a working Salesforce pipeline cheaply, provided your team is willing to own the YAML and the auth setup.

FAQs

Book a discovery call to see how Flosum runs Salesforce CI/CD with fewer manual steps.