Salesforce DevOps rollout: roadmap and metrics

The move from change sets to a Salesforce DevOps pipeline works in phases, not in one big switch. I recommend seven phases in the order of this masterclass: settle ownership and tooling, make Git the single source, build a validation pipeline, switch on quality gates, bring data and configuration along, set a release calendar and secure operations. Each phase ends with a result you can check. One stream goes first as a pilot, and the other partners follow on fixed dates. In parallel you build knowledge in-house, for example with the free sfdx-hardis training, and measure progress against a baseline. Coding agents come once this pipeline is in place.

What does the roadmap from change sets to a pipeline look like?

The nine chapters before this one each describe one building block. For the rollout, the order matters, because each phase depends on the one before:

Phase	What you get	Exit criterion	Chapter
1. Ownership and tooling	You own repository, pipeline and tools; roles and approvals are named	Release manager named, tool decision in writing, rules in every partner contract	1, 2, 4
2. Git as the source	Production metadata in the repository, sandbox strategy, branch model	Every change starts on a feature branch	3
3. Validation pipeline	Pull requests, validation deployments, delta deployments, login without passwords	UAT and production no longer accept change sets	5
4. Quality gates	Mandatory reviews, Apex and Flow tests, static analysis with a threshold	Merge only with a green pipeline and approval	6
5. Data and configuration	Reference and configuration data from the repository, masked sandboxes	No manual data step left in the release plan	7
6. Release rhythm	Release calendar, freeze windows, plan for the three Salesforce releases	Calendar for twelve months published	8
7. Operations	Monitoring, backup, hotfix path, metrics	Restore rehearsed once, hotfix runs through the pipeline	9

Phase 1 needs little technology and decides the most. Whoever picks the tool sets the standard. If the choice comes late, or a client leaves it to the first partner, two partners build two processes and the client pays to merge them. I therefore recommend making the tool decision early and binding for every partner, for the reasons in why clients should own their DevOps tools.

Phase 2 starts with production as the truth. Until the repository exists, the production org is the only complete source. You pull the starting point with sf project retrieve start and a package.xml passed via --manifest, according to the CLI reference (opens in a new tab). From that day on, anyone who changes something in production Setup creates drift, and drift goes back into the repository before the next release runs.

Phases 3 and 4 overlap with a delay. A pipeline that blocks everything from day one meets hundreds of legacy findings in a mature org. Partners then switch rules off instead of fixing code. I would block only severe findings at first and report the rest, as described in quality gates for AI code, and tighten the threshold every quarter.

A pilot goes first. Pick a stream with many small changes and limited risk, such as the dealer portal, not the SAP integration. After two or three releases in the pilot you see where your pipeline sticks, before every partner depends on it. The other streams follow on dates written into the contract. A cut-off date ends change sets for UAT and production; after that there is no exception for “just this one field”.

How do you enable your team and your partners?

Training comes next, and it should be hands-on. I have used sfdx-hardis in client projects for about two years and completed all three levels of the free sfdx-hardis training (opens in a new tab) in October 2026. In 27 labs you build a complete pipeline on free Developer Edition orgs and a GitHub account, and you only get a badge once a job has checked the work in your own repository. Even with prior experience it took me almost a day. My notes are in what I learned from the sfdx-hardis training.

The commercial vendors have their own offers, and I have taken courses from Gearset, Flosum and Copado. Gearset runs DevOps Launchpad (opens in a new tab), a free platform with courses, quizzes and certificates whose content is mostly not tied to Gearset. According to its training page (opens in a new tab), Copado offers the Copado Academy and free workshops that include an exam voucher. Flosum has two courses, Professional and Expert, under Flosum Certified Learning (opens in a new tab). Use the training for the tool you chose; for Git and pull request basics, any of them will do.

Role	What they need to handle	Suitable training
Admins and consultants	Branch, pull request, merge conflict without fear	sfdx-hardis levels 1 and 2, DevOps Launchpad
Developers and tech leads	Deployment steps, quality gates, test coverage	sfdx-hardis level 2, the tool vendor’s training
Release managers	Reviews, UAT, production, hotfix, metrics	sfdx-hardis level 3, the tool vendor’s training
Product owners, business units	Read the release calendar, sign off UAT	no course, one hour with the release manager

I would treat partners like internal teams and require in the contract that every developer shows the basic training and has read the onboarding document in your repository before their first pull request. That costs a day per person and saves the discussion in sprint three about why the partner would like to deploy by change set after all. How this fits into steering several partners is part of my partner governance work.

These mistakes slow the rollout down

These patterns follow from the structure of a programme with several partners, which is why they keep coming back:

• The tool comes before the process. A licence does not replace a branch model, an approval rule or a release manager.
• The first partner sets everything up. Repository and pipeline then sit in their organisation, and a partner change turns into a migration project.
• All streams switch at once. A pipeline fault then stops the whole programme instead of one pilot.
• Production stays open. A quick fix in production Setup creates drift, and the next deployment either overwrites it or fails.
• Gates block everything from day one. The result is switched-off rules and // NOPMD comments instead of better code.
• Only developers get trained. Admins keep building in Setup because nobody showed them pull requests.
• Nobody measures. Without a baseline you cannot show the steering committee what the change achieved.

Measuring progress against a baseline

DORA now describes five metrics (opens in a new tab) for software delivery: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate, the share of unplanned deployments caused by a production incident. The first three measure throughput, the last two instability.

The tools provide part of this. According to its documentation, the sfdx-hardis DORA report (opens in a new tab) computes all five per major branch, as described in chapter 9, and the overview (opens in a new tab) rates the classic four against industry benchmarks. Gearset has a DevOps performance dashboard (opens in a new tab) with the same four, which requires a Teams or Enterprise Automation Platform licence and Pipelines with the promotion branch strategy; change failure rate and time to restore are based on bugs your team reports in promotions. Both figures are therefore reliable only if incidents are reported consistently.

For a programme in rollout, I would add four figures of my own, because they show progress earlier than DORA:

1. Share of deployments through the pipeline among all deployments to UAT and production. The target is 100 percent by the cut-off date.
2. Manual steps in the release plan. Every line someone executes by hand in Setup is a risk on release night.
3. Waiting time until the first review per pull request. If it rises, you are short of review capacity, not developer capacity.
4. Drift findings per month from monitoring, meaning changes in production that did not come from the repository.

Take the baseline before phase 2 starts, from the release plans of the last six months if need be. I would report these figures to the steering committee every quarter on one page, split by stream and partner.

Worked example: three partners, one org

Suppose a machine builder runs Service Cloud, Field Service for its field technicians, a dealer portal on Experience Cloud and an SAP integration for orders and spare parts. Three partners deploy by change set, and every four weeks there is a release with a plan of 60 manual lines. All figures are assumptions.

1. 01

   Settle ownership

   Months 1 and 2 · client

   The client names an internal release manager, decides on a tool and adds an annex to all three contracts with the branch model, the review duty and the cut-off date.

2. 02

   Start the pilot

   Month 3

   The repository is built from production, and the dealer portal stream starts as the pilot.

3. 03

   Validate and train

   Months 4 and 5

   Validation on every pull request, gates block severe findings. The release manager and two admins do the training.

4. 04

   Switch all streams

   Month 6

   The Field Service and SAP partners switch, cut-off date for change sets.

5. 05

   Data and operations

   Months 7 to 9

   Price books and Field Service configuration move into the repository, the release calendar is set, and monitoring reports drift.

After nine months the release plan has twelve manual lines, down from 60, UAT gets new builds weekly instead of monthly, and a partner change in the Field Service stream would be a contract question, not a technical project. These figures are planning values for the example, not measurements.

What changes when coding agents work in the pipeline?

Coding agents write code faster than people can review it. A pipeline with mandatory reviews and blocking gates absorbs that; a pipeline without them just moves it into production faster. That is why DORA lists working in small batches (opens in a new tab) among the capabilities that offset the risk when AI speeds up development. For me the order is clear: phases 1 to 4 first, then agents.

When you get there, the following changes:

• A rules file enters the repository. CLAUDE.md, AGENTS.md or .vibes/rules/ belong to you and have a named owner on your side, see the AI rules file in your Salesforce repository.
• The gates get rules for typical agent mistakes, such as a check whether an agent raised the API version of an Apex class in passing. Details in quality gates for AI code.
• Agentforce agents become release items themselves. Their Agent Script lives in Git and goes through validation, publish and activation, see Agentforce agents in the release pipeline.
• The DevOps tools bring their own agents. sfdx-hardis lists a Coding Agent Auto-Fix (Beta) for deployment errors in its overview, and Copado and Gearset have announced their own agents, which I assess in Copado, Gearset and Provar AI agents: a client check. Every suggestion from an agent passes the same checks and a human review.

Review capacity takes the biggest hit, especially with nearshore teams in other time zones. I have worked with nearshore teams in Eastern Europe and India, and what agents shift there is covered in nearshore Salesforce teams with AI agents.

From here, the AI masterclass takes over. Which coding agent suits your team or partner, and what the contract needs to say about it, is covered in chapter 4 of the AI masterclass. How roles, review gates and metrics change when teams deliver with agents is in chapter 9 of the AI masterclass. The operations this phase builds on are described in the previous chapter 9 on operations and monitoring, and all chapters of this masterclass are on the overview page. I support the rollout itself as part of DevOps and release management.