DevOps involves a range of tools and processes, but fundamentally it’s a methodology or way of working — meaning DevOps adoption is never an overnight switch, but an ongoing commitment to adopt its principles and practices. There’s also no single “correct” way to adopt DevOps, especially in the Salesforce world where delivery teams come in all shapes and sizes.
But that can leave teams confused about implementing DevOps. Where do you begin? What steps need to come before others? What’s the end goal?
In this guide to finding Salesforce DevOps success, we’ll outline a roadmap for adopting DevOps. It’s not a “one size fits all” model, but a typical pattern. It shows how the average Salesforce team tends to introduce new tools and processes to support the different stages of the DevOps lifecycle.
Salesforce DevOps adoption in 2025
It’s worth highlighting that the vast majority of Salesforce teams are somewhere along the road to adopting DevOps. Gearset’s State of Salesforce DevOps 2025 report shows that 87% of Salesforce teams have or are looking to implement DevOps tools and practices.
DevOps tools underpin DevOps practices
There’s a logical sequence for adopting DevOps tools — version control before CI/CD automation tools, for example. And the data shows that teams are picking up those tools in that order: 65% have implemented version control; 55% practice CI/CD.
Backup is quite widely adopted (70%) though not every team has backups well integrated with their broader Salesforce tech stack. Newer areas for the Salesforce world currently have lower adoption rates for tooling: observability (31%) and change intelligence (26%).
But DevOps principles are fundamental
A plan to implement DevOps shouldn’t be a checklist of tools, but a set of principles that will help your team to achieve their goals. What are the essential DevOps principles? You’ll find a variety of thoughtful answers, such as the CALMS framework from Atlassian. But with different emphases, these frameworks all address a similar set of principles:
Collaboration
The origin story of DevOps was all about bringing together development (“Dev”) and operations teams (“Ops”) to break down team silos. In the Salesforce context, the teams might be different — low-code admins and pro-code developers, for example — but the principle is the same: bring teams together to share responsibility for their overall performance. A culture of collaboration is foundational for DevOps.
Iteration
Where the standard development lifecycle is generally depicted as a circle, the DevOps lifecycle is shown as an infinity loop. This represents the agile, iterative approach to the entire development process, in contrast to legacy approaches to release management such as the waterfall methodology.
There’s a strong connection here to the “7 Cs” of DevOps: continuous development, continuous integration, continuous testing, continuous deployment/delivery, continuous monitoring, continuous feedback, and continuous operations. Teams should also aspire to a culture of continuous learning and continuous improvement, taking the right lessons from each development cycle.
Automation
Once any given step in a workflow is repeatable and reliable, it should be automated if at all possible. Automation reduces the manual effort spent on releases, freeing up developers to spend more time on the development phase. Even more importantly, automation makes it possible to achieve the iterative and continuous processes associated with DevOps.
Security
DevOps sometimes has a reputation for being about speed alone, without due care for quality and security. In fact, the DevOps philosophy is that collaborative, iterative, automated ways of working help teams to achieve higher quality and enhanced security practices.
Shared accountability for security and a low-blame culture encourages quick reporting of vulnerabilities, honest diagnosis of mistakes, and widespread uptake of security best practices. Making change incrementally reduces the risk of each deployment, and shrinks the surface area for testing. Automation takes away the risk of human error from repetitive processes.
Some like to use the term “DevSecOps” to emphasize this commitment to integrating security within DevOps and the necessity of bringing security teams into the fold. This can have the unfortunate effect of implying that DevOps itself has little regard for security, when the reverse is true.
Drivers and barriers for development teams implementing DevOps
The drivers for Salesforce DevOps and the barriers faced by teams reflect the complexity of DevOps adoption. Budget constraints relate to tooling. Lack of buy-in, training or prioritization all highlight that a culture shift is needed. Security and compliance challenges should be addressed with tools, process and culture. For a successful DevOps implementation, you’ll need to consider all three.
San Francisco
Dreamforce
Mapping DevOps adoption with the DevOps lifecycle
If DevOps tools are just part of the picture, and DevOps principles are an open-ended commitment to a new way of working, is there anything more definite to aim for? The DevOps lifecycle gives you a complete view of the essential stages that make up your complete development process. This is the best roadmap for guiding your implementation of DevOps.
But where do you begin with the lifecycle? Attempting everything in one go would be overwhelming, so you’ll need to consider which stage to focus on first. Your team should really diagnose performance in each area and evaluate how new tools, better processes and changed culture could help. But you’ll probably find yourself somewhere on the journey we’ll outline in the rest of this article.
Start at the release stage: get quick wins with proper deployment tooling
Releases are a non-negotiable step for every development team. For Salesforce teams pre-DevOps adoption, releases are also error-prone, time-consuming, and risky, which is why most teams already know they want to start here. Releases are where they feel pain right now.
Salesforce teams typically start by looking for a deployment solution to make releases less painful. At this stage, they might not be thinking about DevOps more broadly — they’re just focused on solving that immediate pain. Deployments with change sets, DevOps Center or the Salesforce CLI are where teams see friction, which prompts them to look for a replacement deployment tool.
There are real and significant improvements that teams will achieve with Gearset’s deployment solution alone, including:
- Total visibility on the differences between environments
- Ability to move metadata easily between orgs and version control
- Dependency analysis to any depth
- Visualizers for metadata types such as Flows and Layouts
- Problem analyzers designed to ensure deployment success
- Testing for any Apex classes being deployed
- Team collaboration on deployment packages
- Cloning and combining packages
- Scheduled deployments
- Full or partial rollback
- A full audit trail of deployments
With all those features, teams see much more deployment success. And because deployments are much faster, teams can increase their release frequency.
Shift left: improve quality and efficiency with the right testing strategy
But focusing on deployment tooling and process alone doesn’t solve every problem you run into at release, because some of them aren’t really release problems the pain is just felt at the release stage.
To address the root cause of these problems, development teams need to “shift left”. That is, they need to catch problems at the earliest possible opportunity, when they’re easiest and cheapest to fix.
Shifting left to the build and validate stages
Imagine your team is collaborating on a new feature. You really don’t want to wait until you’re nearing release day to find out:
- Will everyone’s changes integrate properly?
- Will the feature perform as intended in live environments with real data?
- Is our code and configuration secure, efficient, and consistent?
- Are we hitting the 75% code coverage threshold with our unit tests?
These questions need to be answered earlier, shifting left to the validate or build stages of the lifecycle. With continuous integration, all work should be continuously tested as it’s combined, with any merge conflicts handled along the way. Code analysis and automated code reviews should flag security vulnerabilities and non-compliant Apex classes and Flows, so developers can get them fixed along the way.
Shifting left to the plan stage
Now let’s imagine some different scenarios, that can happen even when there are no concerns about functionality, quality, and security because the necessary fixes and improvements have been made during the build and validate stages:
- A feature gets to UAT, only for end users to say it doesn’t meet their requirements.
- Your team is busily working on a feature, but then the business says it’s no longer needed and the work is abandoned.
- You release a feature successfully, but there’s no uptake in production.
These are failures at the plan stage of the lifecycle, and the “shift left” mindset needs to be pushed back to the beginning of each cycle. Is everyone definitely aligned on what needs to be built and why? Does everyone understand the current state of the org? Is it clear what success would look like? Have all relevant stakeholders been included in the decision-making process? A little more focus on getting the plan right saves a lot of wasted time and effort.
The cultural element of good planning is vital: collaboration and communication are critical. But tools can help as well. Org intelligence massively reduces the time it takes to understand the current state of your orgs in the planning stage.
Look right: close the visibility gap and complete your process
While we’re coming to them last in this article, we could have made a compelling argument for paying attention to the operate and observe stages first. Securing and understanding your org is the solid foundation you need to innovate safely. And as we’ve said, there’s no “right” way to adopt the lifecycle, so your team may decide to do just that.
But in reality, when it comes to DevOps adoption for Salesforce, the “Ops” side of things has generally lagged behind partly because Salesforce handles some operations for you. Its shared responsibility model means it takes care of your infrastructure and offers a safety net for worst-case scenarios, while you’re responsible for your data and metadata on the platform.
It’s your responsibility to build a solid backup and restore process, so you can recover quickly from any incident and keep your Salesforce orgs operational. It’s also your responsibility to implement observability tools, so you can understand how your work is performing in production. Backups and observability are a given for DevOps teams on other development platforms. Without them, you’re developing in the dark and running a risk with every release.
Investing in these stages becomes a no-brainer once you’ve already invested in releases and have embraced a “shift left” approach. You’ve gained the ability to release quickly, but do you have the confidence to release more frequently? You’ve driven down change failure rates by shifting testing and analysis to the left, so why aren’t you doing anything to identify the breaking changes and errors in production?
Choosing the right tools for Salesforce DevOps
The DevOps lifecycle represents the complete process your team is aiming to bring in line with DevOps principles, making it the best guide for DevOps adoption. The lifecycle doesn’t imply a specific set of tools and workflows, and that’s important. Each team will need a slightly different toolset, and will need workflows that match the makeup of their team and business context.
But without giving a prescriptive checklist of tools, it’s still useful to be aware of different categories of tooling for Salesforce DevOps:
| Tooling category | Description |
|---|---|
| Ticketing (“ALM”) | Assign development tasks and track their progress through to completion — usually up to release. |
| Org intelligence | Analyze your metadata to understand the current state of your org, and how to go about planning new work. |
| Test automation | Run unit and UI tests to ensure code and config function as intended. Test during development and continue testing in production. |
| Automated code reviews | Get config and code analysis throughout development, flagging issues with security, quality and consistency. |
| Sandbox seeding | Migrate production data to lower environments so that testing orgs replicate real-world environments. Mask records for security and compliance. |
| Deployments | Eliminate manual change tracking, simplify deployments, and enable rollbacks. |
| Version control | Collaborate within and across teams, without treading on each other’s toes. |
| Pipelines | Implement continuous integration and continuous delivery (CI/CD) to automate testing and promotion through the release pipeline. |
| Backup | Protect your data and metadata with regular, automated backups and a tested restore process. |
| Archiving | Remove obsolete data from your org to reduce data storage costs and improve data quality, while remaining compliant. |
| Observability | Proactively catch issues in production such as Flow and Apex errors, and use the insights to plan future improvements. |
| Auditing | Keep a record of who has changed what, to meet compliance requirements. |
| Reporting | Monitor DevOps performance improvements, e.g. using the DORA metrics, so you can demonstrate business impact and Salesforce ROI. |
Gearset: the DevOps platform that brings everything together
Given the number of tooling categories, as we saw above, an obvious challenge with point solutions is that a broad DevOps implementation will result in multiple tools and vendors to manage.
Gearset’s platform covers the full lifecycle with our own solutions in every category, except ticketing and version control, where the vast majority of teams want to use their tools (e.g. Jira and GitHub) for consistency with the rest of their business. We have tight integrations with all major ticketing and VCS providers.
Rather than twenty tools covering different tasks in your development lifecycle, you can get all the tools you need for the whole DevOps lifecycle using, for example, Gearset, Jira, and GitHub. This takes for granted the “build” tools you use: Salesforce developer environments and an IDE like VSCode (which is free). Salesforce DX (also free) can be used within and alongside Gearset as well.
It’s intuitive that teams perform best when they can manage their end-to-end process from one shared platform. And the data confirms that this is the case. The State of Salesforce DevOps 2025 report demonstrates a strong correlation between fewer tools and better performance even factoring for variables like the size of organization or DevOps maturity.
DevOps teams consider the full lifecycle — Salesforce teams should too
Not many years ago, most Salesforce teams hadn’t heard of DevOps. Now the situation is reversed. But relatively few teams have adopted mature processes and tooling right across the Salesforce DevOps lifecycle. As the performance gains for quality, speed and security of delivery become increasingly clear, DevOps adoption will continue at pace in the Salesforce ecosystem.
On other development platforms, the tools and processes covered in this article are generally assumed to be essential. Salesforce teams deserve the same toolsets to ensure success on a critical platform for their business.
Get in touch with us today to arrange a tailored demo of Gearset, so you can see how the platform will help you implement or improve your Salesforce DevOps process.
