Chapter 1 of 10DevOps masterclass
Salesforce release management: the basics
Salesforce release management decides whether a programme with several partners stays predictable. Once two teams work on the same org, pushing changes from sandbox to sandbox with change sets no longer works. You need a Git repository as the single source of truth, a pipeline that checks and rolls out every change the same way, and clear rules on who approves what and when. Repository, pipeline and tools belong to you as the client, not to the implementation partner. The way there has five stages from change sets to your own pipeline, and none of them requires a big bang.
What does release management mean for Salesforce?
Release management is the discipline of moving changes to a Salesforce org from development to users in a planned, checked and traceable way. DevOps describes the way of working and the tools behind it. In conversations with business units and partners the same terms come up again and again, and people often mean different things by them. This is how I use them in this masterclass:
Terms
Seven terms as I use them in this masterclass
- Source-driven development means the version control system, not the org, is the source of truth. The Salesforce DX Developer Guide (opens in a new tab) puts it briefly: "Instead of the org, your version control system is the source of truth." Whatever is not in the repository does not count.
- Version control is a system such as Git that stores every version of every file with author, time and reason. Every change can be traced, compared and reverted. For Salesforce it holds metadata such as objects, fields, flows, permission sets and Apex classes as files.
- Continuous integration (CI) means every change is checked automatically before it is merged into a shared state. For Salesforce that is a validation deployment, Apex tests and static code analysis.
- Continuous delivery (CD) means checked changes can be rolled out to the next environment automatically at any time, without manual steps from a spreadsheet.
- Pipeline is the fixed sequence of environments and automated checks every change passes through, for example developer sandbox, integration, UAT, production. Every change takes the same route, hotfixes included.
- Deployment is the technical transfer of metadata into an org. For a production deployment that includes Apex, the Salesforce CLI reference (opens in a new tab) runs all local tests by default, and according to the Apex Developer Guide (opens in a new tab) tests must cover at least 75 percent of the Apex code and all of them must pass.
- Release is a planned set of changes that goes live for users on a fixed date. It includes communication, training and sign-off by the business.
For decision makers the difference between deployment and release matters most. Deployments can run daily, in sandboxes even several times a day. A release is a business decision: the head of service decides from which day field technicians use the new job completion screen. If you mix the two up, you either plan too few deployments and get huge, risky packages, or you switch features on before the business is ready.
One set of dates is never yours. According to its release overview (opens in a new tab), Salesforce ships three seasonal releases a year, typically Spring in February, Summer in June and Winter in October, with a sandbox preview of four to six weeks beforehand. Your release calendar has to work around these dates. Chapter 8 covers how.
What do bad releases cost in a programme with several partners?
I have worked in a programme with eight teams and 32 developers, on orgs where several implementation partners worked at the same time, and with nearshore teams in Eastern Europe and India. Without a shared release process, the same patterns appear every time; I describe them in more detail in why DevOps decides Salesforce enterprise projects. For a budget they translate into five kinds of cost:
| Cost type | What happens |
|---|---|
| Rework across team boundaries | Team A deploys a page layout, team B deploys the same object with an older version a day later. The fix ties up both teams, and with distributed teams across time zones every alignment takes longer. |
| Repeated testing | Every faulty deployment to UAT invalidates other teams’ test results. Key users from sales and service test the same cases twice and lose trust in the sign-off. |
| Downtime for the business | In manufacturing, a production defect often hits the processes with the most customer contact: service orders, spare parts orders in the dealer portal, the order handover to SAP. |
| Growing packages | Teams with bad release experiences release less often. Less frequent releases get bigger, bigger releases get riskier. The five DORA metrics (opens in a new tab) make this measurable, for example deployment frequency and change fail rate, the share of deployments that need immediate rework such as a rollback or an emergency patch. |
| Dependency and blame | Without history in the repository nobody can show which partner made which change. Arguing about it costs steering time and strains the collaboration. |
Suppose a machinery manufacturer runs Service Cloud with Field Service, a dealer portal on Experience Cloud and an SAP interface. Three partners work on the same org, one each for service, sales with the portal, and integration. On Friday evening the sales partner deploys a new validation rule on the order object with a change set. It is correct in the partner’s sandbox, but it does not know a field the integration partner introduced two weeks earlier. On Monday the nightly order handover from SAP fails, dealers see no delivery dates, and the service team has to postpone its own UAT run because the org is unstable. None of these costs shows up as its own line in the project budget. A validation deployment against the shared state in the repository would have shown the conflict before the merge.
Change sets are no longer enough for several partners
Change sets are the standard tool many orgs start with, and for a single admin they are fine. According to Salesforce Help (opens in a new tab), they need a deployment connection, which only exists between orgs affiliated with the same production org. They contain only changes you can make in Setup, no records, and they are deployed as a whole. For a programme with several partners the decisive things are missing:
Change sets
- No version history, so no comparison and no clean rollback
- No review before a change reaches the next environment
- No automated checks against other teams' work
- Components are clicked together by hand, and something is easily missed
- No record of who changed what, when and why
Repository and pipeline
- Every version sits in Git with author and reason and can be rolled back
- Every change goes through a pull request with review
- A validation deployment checks against the shared state
- The pipeline always deploys the same package, without manual work
- The history shows which partner changed what
The core problem is the source of truth more than the tool. As long as the org is the truth, the last person to deploy decides which version counts.
Five maturity stages from change sets to a pipeline
Hardly any company jumps straight from change sets to a fully automated pipeline, and it does not have to. I place programmes in five stages. Each stage has a clear benefit, and each one prepares the next. Two transitions are the hardest in practice.
- 1Clicks and change setsIn Setup or by change set, by handChapter 1
- Biggest riskOverwrites, no history
- 2Repository as a backupStill by hand, metadata is also saved to Git; Git is a copyChapters 2, 3
- Biggest riskRepository and org drift apart
- 3Pull requests with checksChanges are built in a branch, every pull request gets a review and a validation deploymentChapters 4, 5, 6
- Biggest riskChecks get bypassed while production stays open
- 4Pipeline to productionEvery environment, production included, only through the pipeline, with delta deployments and a hotfix pathChapters 7, 8
- Biggest riskData, configuration and Salesforce releases stay manual
- 5Operations and measurementAs stage 4, plus monitoring, backups and metricsChapters 9, 10
- Biggest riskThe process ages when nobody owns it
Source of truth: the org
Source of truth: the repository
From stage 2 to 3
The step moves the source of truth from the org into the repository.
From then on, every change made directly in a shared org is a process failure.
From stage 3 to 4
The step closes the back door.
As long as someone with admin rights may deploy to production, the pipeline is only a recommendation.
The validation deployment is the first tool that pays off as early as stage 3.
For developers
How do validation and quick deploy work?
With sf project deploy validate the Salesforce CLI (opens in a new tab) checks whether a deployment would succeed without changing anything. After a successful validation the package can be rolled out by quick deploy for up to ten days without running the tests again.
Stages 3 to 5 need a tool. One open-source option is sfdx-hardis (opens in a new tab), maintained by Cloudity with a community; it ships pipelines for GitHub, GitLab, Azure DevOps, Bitbucket and Jenkins as well as monitoring and metadata backup. I have used it in client projects for about two years. Commercial platforms such as Gearset (opens in a new tab), Copado (opens in a new tab) or Flosum (opens in a new tab) offer a managed interface, vendor support and less operating effort on your side; Flosum describes itself as a native solution on the Salesforce platform. Chapter 4 compares which tool fits which programme. For this chapter two rules count: the choice is made early and binds every partner. And if open source saves you licence costs, the money is best spent on an internal release role.
Who owns the release process?
You do. That is the basic assumption of every chapter that follows. Repository, pipeline, DevOps tool and sandboxes are in your name, and partners get personal users with the rights their task needs. Why the same applies to Jira, Confluence and Miro is in why clients should own their DevOps tools.
The second principle: every change goes through a pull request with a review, flows and permission sets included. The review is the cheapest point at which a programme with many teams agrees on one way of building. What a good review checks is in why pull request reviews are a must.
Both principles are governance questions and belong in the contracts with your partners. That is where I start in DevOps and release management and in partner governance.
The path through the ten chapters
The masterclass follows one company along this path. Each chapter builds on the previous one.
| No. | Chapter | The question behind it |
|---|---|---|
| 1 | Why releases decide | Which terms, which costs, which maturity stage? |
| 2 | Ownership and roles | Who owns what, who approves what, what goes into the partner contract? |
| 3 | Environments and branches | Which sandboxes, which branch model, which hotfix path? |
| 4 | Tools compared | Salesforce standard tooling, open source or a commercial platform? |
| 5 | Building the pipeline | How do pull request, validation, tests and deployment work? |
| 6 | Quality, tests, reviews | Which quality gates must every change pass? |
| 7 | Data and configuration | How do price books, product data and configuration records move along? |
| 8 | Release planning | How do your own calendar and three Salesforce releases fit together? |
| 9 | Operations and monitoring | What happens after go-live, and how do you measure stability? |
| 10 | Rollout and roadmap | In which order do you introduce all of this? |
Chapter 10 also builds the bridge to coding agents in the pipeline. For more on that, the AI masterclass has a chapter on teamwork and delivery.
Where do you stand today?
Six questions are enough for a first assessment. You should be able to answer each in one sentence:
- In whose name are the Git repository and the DevOps tool?
- Can anyone change something in Setup in production today without it showing up in the repository?
- Does every change go through a pull request with a review, including those from the partner with the biggest team?
- Which version is in UAT right now, and how do you know?
- Who approves a release, and who decides on a hotfix?
- How long does it take to take back a faulty change in production?
If you hesitate on more than two of them, your programme is at stage 1 or 2. Then settle ownership and roles first and the tool after that. The path continues in chapter 2: ownership and roles.
Frequently asked questions
What is the difference between a deployment and a release?
A deployment moves metadata into an org; it can happen every day. A release is the planned go-live of a set of changes for users, with a date, communication, training and sign-off by the business.
When is a pipeline worth it instead of change sets?
As soon as a second team or a second partner works on the same org. From then on changes overwrite each other, and without a repository nobody can show who changed what and when.
Do I need a commercial DevOps tool to start?
No. A Git repository, the Salesforce CLI and an open-source option such as sfdx-hardis are enough for a complete pipeline. Commercial platforms such as Gearset, Copado or Flosum add a managed interface and vendor support. What matters is that the choice is made early and applies to every partner.
Who should own the release pipeline?
You, the client. Repository, pipeline and tools are in your name, and partners work in them with personal users. That keeps the process stable when a partner changes.