Many Salesforce teams still release the way they did years ago: build in a sandbox, collect components into a change set, test manually, deploy on a Friday evening and hope. It works until the org grows, several people change the same objects and a small Flow update quietly breaks an integration.

Salesforce DevOps replaces hope with a repeatable process. This guide covers the building blocks: environments, source control, CI/CD, test automation, quality gates and metrics, plus a sample pipeline and a 90-day plan to adopt it.

What does DevOps mean on Salesforce?

• Source-driven development: metadata lives in version control, which becomes the source of truth.
• A deliberate environment strategy for development, testing and user acceptance.
• Continuous integration: every change is validated automatically before it is merged.
• Continuous delivery: validated changes deploy to each environment the same way, every time.
• Automated testing at several levels, with quality gates that stop bad releases.
• Measurement: tracking delivery speed and stability to improve over time.

Which Salesforce sandboxes do you need?

Use a class implementing the SandboxPostCopy interface to run set-up automatically after a refresh, such as masking email addresses or disabling outbound integrations.

Source control and branching

• Use a Git provider your organisation already supports, with pull requests and required reviews.
• Structure the project in Salesforce DX source format.
• Prefer short-lived feature branches merged frequently into a main branch; add release branches only if your release cadence requires them.
• Be deliberate about difficult metadata: profiles, permission sets, page layouts and destructive changes need explicit handling.
• Consider unlocked packages to modularise large orgs once the team is comfortable with source-driven development.

Which Salesforce DevOps tools should you use?

How do you manage profiles and permission sets in source control?

Access metadata causes more failed and surprising deployments than almost anything else. What a retrieved profile contains depends on which other components are retrieved with it, so deploying a profile can unintentionally overwrite permissions. A sustainable approach:

• Keep profiles minimal and grant access through permission sets and permission set groups, which deploy more predictably.
• Create one permission set per business capability, name it clearly and review changes in pull requests like code.
• Avoid deploying whole profiles; if you must, retrieve them together with all the objects, fields and classes they reference.
• Include access changes in the same pull request as the feature that needs them, so they are tested together.

The Salesforce test automation pyramid

Salesforce requires at least 75% Apex code coverage to deploy to production, but coverage alone proves little. Good tests create their own data, test positive, negative and bulk scenarios, and assert outcomes. If you are hiring for this skill, our list of Salesforce developer interview questions includes what good test practice looks like.

A sample Salesforce CI/CD pipeline

1. Pull request opened: run static analysis and component tests, then a check-only deployment to a CI org running relevant Apex tests.
2. Review and merge: at least one reviewer approves; the pipeline must pass.
3. Deploy to QA sandbox: automatic deployment and automated regression tests, including a small UI smoke suite.
4. Deploy to UAT (Full sandbox): business users test release candidates.
5. Validate against production ahead of the release window.
6. Release: quick deploy the validated deployment, then run post-deployment smoke tests.

A minimal pull request validation job with GitHub Actions and the Salesforce CLI might look like this:

name: validate-salesforce
on:
  pull_request:
    branches: [main]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install --global @salesforce/cli
      - run: npm ci && npm run test:unit
      - name: Authenticate to the CI org
        run: |
          echo "${{ secrets.SF_CI_AUTH_URL }}" > auth.txt
          sf org login sfdx-url --sfdx-url-file auth.txt --alias ci
      - name: Check-only deployment with Apex tests
        run: sf project deploy validate --source-dir force-app --target-org ci --test-level RunLocalTests --wait 60

Store the authentication URL as an encrypted secret, use a dedicated integration user with only the permissions deployment needs, and never commit credentials to the repository.

Quality gates worth enforcing

• No high-severity security findings from static analysis
• All Apex and component tests pass
• Coverage for changed classes at or above an agreed threshold, often higher than the platform minimum
• No failed UI smoke tests on critical journeys
• UAT sign-off recorded for business-facing changes
• Release notes and rollback steps prepared

Test data management

• Use test data factory classes so Apex tests never depend on org data.
• Seed scratch orgs and developer sandboxes with scripted, realistic sample data.
• Mask or anonymise personal data in sandboxes created from production.
• Keep integration endpoints in sandboxes pointed at test systems through Named Credentials.

Handling urgent hotfixes

Production issues will still happen, so define the hotfix path before you need it: branch from the version currently in production, fix and test in a dedicated sandbox, run the same validation and tests as a normal release, deploy, and then merge the fix back into the main branch immediately so the next release does not reintroduce the bug. Skipping the pipeline "just this once" is exactly how orgs drift out of sync with source control.

Measure delivery performance

The widely used DORA metrics translate well to Salesforce:

• Deployment frequency: how often you release to production
• Lead time for changes: time from commit to production
• Change failure rate: the share of releases causing incidents or rollbacks
• Time to restore service: how quickly you recover from a failed change

Common mistakes

• Treating production as the source of truth and back-filling Git afterwards
• Writing tests only to reach coverage
• Automating fragile UI tests for everything instead of critical journeys
• Letting sandboxes drift far from production
• Skipping destructive change management, leaving unused metadata behind
• Introducing tools without changing team habits and responsibilities

A 90-day adoption plan

1. Days 1–30: retrieve metadata into Git, agree branching and review rules, set up pull request validation, and fix failing Apex tests. Our org health check helps find them.
2. Days 31–60: automate deployments to QA and UAT sandboxes, add static analysis and component tests, and document the release process.
3. Days 61–90: build a UI smoke suite for five to ten critical journeys, introduce quality gates, start tracking DORA metrics and retire change sets.

Build a reliable Salesforce release process with Groviya

Groviya’s quality engineering and Salesforce teams set up DevOps pipelines, write meaningful Apex and component tests, and build automated regression suites for Salesforce and custom applications. See our quality assurance and testing services or talk to a DevOps specialist.