Skip to content
Salesforce DevOps Center

Salesforce DevOps Center Launches with High Expectations

Salesforce last week finally announced General Availability of DevOps Center, a new Salesforce feature designed to ease application development and release management. DevOps Center was originally introduced under “safe harbor” in late 2019, so this announcement culminates one of the most anticipated releases of a Salesforce feature in the last few years. “DevOps Center is one of our most-requested and most-anticipated solutions ever because it increases efficiency and productivity – and it makes work easier and more accurate for thousands of development teams. It’s now easier than ever to manage changes, collaborate with team members, and ensure you have a synchronized source. And, it’s designed for fusion teams made up of developers across the low-code and pro-code continuum, so you can work inside or outside the DevOps Center UI-based app and everything remains in sync,” said Karen Fidelak, a senior director of product management at Salesforce, in a press release.

What is Salesforce DevOps Center?

DevOps Center is a new Salesforce feature that lets admins, low code developers, and application developers safely and easily deploy changes to a production org. To do its work, DevOps Center relies heavily on the Salesforce org source tracking features found in scratch orgs and some sandbox types. This lets DevOps Center automatically determine meta data changes in development orgs, update GIT repositories, and then deploy change artifacts to testing and production orgs in a managed devops pipeline.

Ben McCarthy, the founder of, was asked what DevOps Center means for the Trailblazer community. “The Salesforce DevOps Center is an exciting product release for the ecosystem. It will not only change the way Salesforce professionals deploy changes, by bringing out a successor to change sets, but a new mindset, to meet modern DevOps best practices. This is exciting for both the businesses that use Salesforce, as they can accelerate development in a safer way, and the Salesforce professionals that will add another skillset to their repertoire,” said Mr. McCarthy in email correspondence.

Pablo Gonzalez, a Salesforce architect who writes about CI/CD and the Salesforce API at, was blunt about how he thinks DevOps Center is about to make some waves in the Trailblazer community. “The release of DevOps Center forces everyone to think about DevOps. Before its release, we could still hide behind the comfort zone of change sets. Now, Salesforce is sending a strong signal: Git-based deployments and pipelines are the way to deploy changes across your Salesforce orgs,” said Mr. Gonzalez in email correspondence.

As everyone says, the biggest expectation of DevOps Center is to reduce or eliminate the use of change sets to deploy sandbox changes back to a production org. Based on my personal experience, DevOps Center has achieved that important goal.

Using DevOps Center

Here is a description of how I now use DevOps Center to deploy projects using sandbox changes. To get started, I first enabled source tracking in sandboxes before making a new sandbox. I then generated a Developer or Developer Pro sandbox for development work. Partial Data and Full Data sandboxes don’t do source tracking, so you’ll need a data loading routine to populate your sandboxes with data for development activities.

Another preparation activity I did was to create a new GitHub repository for this project. Currently you must use GitHub, but Salesforce is working on other online GIT systems.

After installing DevOps Center as a managed package, I followed these important installation instructions to create a connected app called DevOps Center that appeared in my Salesforce app menu. I then picked DevOps Center in the app menu item, which gave me a list of my projects.

After creating a new project and linking it to a GitHub repository, I linked my production and sandbox environments in the project’s Environments tab. Next, I created a Work Item that described a small set of changes I wanted to deploy to production. I then went into the sandbox and made changes to Flows interactively and to Apex from VS Code. I next ran unit and functional tests to make sure my changes were ready for deployment.

Back in DevOps Center, I went into the Work Item. I then commanded DevOps Center to detect all the changes made in the sandbox. Next, I used the Pipelines feature in DevOps Center to pick my Work Item and deploy it to my production org. Overall, I found that DevOps Center made it easy to replace my old change set workflow with a simple user interface.

Who Needs Salesforce DevOps Center?

Since DevOps Center is now an easy-to-use tool built into the Salesforce interface, every organization that currently customizes its Salesforce org with change sets is a potential user. Ian Gotts, the founder and CEO of, is excited about this product launch. He thinks DevOps Center will help most Salesforce customers streamline development activities.

“The implementation of DevOps Center now enables 50,000 organizations to reengineer their implementation processes and reduce rework by up to 80%. DevOps Center helps those organizations think about efficiency and building the things right,” said Mr. Gotts in our email correspondence.

Interestingly, DevOps Center has an opinionated approach to devops. Due to this, it is more targeted towards those Salesforce customers who have mission-critical applications which require governance.

For those customers with mission-critical apps, Salesforce has been pushing its Well Architected program to help with governance. Now, DevOps Center brings the Well Architected program to life by following Salesforce’s recommendations on how to perform branch-based app development. Here is how that works. As changes are ready for testing, DevOps Center does the job of packaging and moving those changes through a specific sequence of Salesforce orgs. These separate environments are designed to facilitate testing and user acceptance of org changes in a rigorous and governable manner.

Before DevOps Center, if a Salesforce customer wanted to do branch-based development and follow the Well Architected program, then a release program manager would likely be required. That person would usually track and manage all the environments and deployment payloads using GitHub, a spreadsheet, or other tools. Now, with DevOps Center automation, the release management process may be partially tracked and managed with Salesforce itself. This lowers personnel requirements and enables more Salesforce customers to follow the Well Architected roadmap.

Salesforce DevOps Center Architecture

The most interesting aspect of DevOps Center to me is how it leverages the source tracking feature of Salesforce DX. This is nice because source tracking addresses several enduring problems in Salesforce development. These problems include managing a dynamic meta data environment and bringing low code developers into formal release management.

As an adjunct to how Salesforce manages metadata, source tracking gives Salesforce DX developers access to metadata intelligence with simple “pull” and “push” commands. Now, DevOps Center makes using source tracking even easier with a simple user interface. As a result, I like how DevOps Center now gives low-code app creators a way to access powerful metadata intelligence capabilities.

Another significant architectural feature of DevOps Center is its open approach to project management. As a managed package, DevOps Center introduces the Work Item custom object into the host org’s schema. Salesforce has encouraged independent software vendors (ISVs) to use the Work Item object as a touchstone between DevOps Center and their software systems. Due to this openness, two ISVs, and Prodly, have implemented integrations with DevOps Center.

David Clark, the vice president of Product at Prodly, is excited about how DevOps Center is now increasing interest in some of Prodly’s product features. “We found that Salesforce DevOps Center had no plans to help customers migrate data or seed sandboxes, so we took the opportunity to build an integration between Prodly and DevOps Center. Now customers can manage all their development needs using platform native tools designed for admins,” said Mr. Clark in email correspondence.

However, DevOps Center lacks a key feature which all the Salesforce DevOps platforms have, which is to command a sequence of long-running activities. Most people call this feature a CI/CD engine. But since I discourage the use of acronyms, I prefer to call this function a Scripted Command Server. Without a scripted command server, Salesforce DevOps Center cannot be considered as a devops platform. There has been talk about adding this later, but I’m hoping for CLI access instead. A CLI used to command DevOps Center actions would be very useful from within a GitHub Action.

David Brooks, who is senior vice president of Products at Copado, believes their scripting engine will help them keep their enterprise customers. “Copado pioneered the concept of User Story-driven pipelines and our offerings – from Essentials to full CI/CD – provide users more advanced capabilities, including access to data deployment and automated testing. Customers like Telecom Argentina, Weave and Valmet routinely tell us they can scale fast, accelerate release cycles, improve quality, and reduce risk with Copado DevOps and testing,” said Mr. Brooks in email correspondence.

Salesforce DevOps Center Industry Impact

The most frequent question I get is whether Salesforce DevOps Center is a replacement for a Salesforce devops platform vendor like Copado, Prodly, or Opsera. And the simple answer to that question is a firm no. This is because DevOps Center is a tool, not a platform. For starters, DevOps Center does not have a scripted command server. And Devops Center is highly opinionated on how you should manage your devops pipeline.

Besides missing the command server, Devops Center lacks additional features one should expect in a Salesforce devops management platform, including:

  • Application Lifecycle Management (ALM) – While the Work Item object is nice, DevOps Center lacks sophisticated project management. It would be nice to have Jira integration out of the box, but that is not currently available from Salesforce.
  • Metrics and Observability – You must measure your work to gain productivity, especially in big enterprises. I hope we eventually see DevOps Center have Tableau integration on DORA metrics gathered during operations. DORA refers to an accepted set of devops performance measurements: deployment frequency, lead time for changes, time to restore service, and change failure rate.
  • Value Stream Management – It would be nice to see the Well Architected program grow to emphasize even more alignment with business practices and key performance indicators (KPIs). Salesforce should give customers tools that link enterprise value streams to dashboards, ALM, and other devops activities. This is ultimately required for customers to know they are building the right digital products.
  • Cybersecurity – I see Salesforce devops cybersecurity divided roughly into two categories: developer cybersecurity and platform cybersecurity. These categories cover the requirements of static application security testing plus configuration management and testing.
  • Functional Testing – When building digital products, more testing performed during development tends to reduce outages and other production failures. Most devops pipeline managers employ first and second-generation testing tools in development environments prior to deployment.
  • Multi-SaaS Capabilities – Most enterprises orchestrate activities between several SaaS systems at once. The most complete Salesforce devops platform vendors not only support Salesforce, but help their customers manage metadata and configurations of other SaaS systems.
  • Ancillary Meta Data Management – Salesforce customers who use CPQ, B2B Commerce, or one of the industry packages are usually faced with managing extensive sets of configuration data.

Ian Gotts from is excited about DevOps Center, but he points out it lacks any substantial ALM capabilities. “But when using DevOps Center, your needs also include building the right things, and that means rigorous analysis. This is enabled by with support for every phase of business and org impact analysis, and the integration which overcomes many of the current limitations of DevOps Center,” added Mr. Gotts in our email correspondence.

Here is another way to position DevOps Center within the Salesforce ecosystem. If you are a follower, you may recall the Salesforce and SaaS Devops Industry Map which outlines 11 different solution categories needed for a complete devops management program. I organized the map so that the categories with greater complexity are at the top of the stack.

DevOps Center only covers the bottom two layers of the Salesforce devops solution stack. Since some of the other devops platform providers cover nearly all the stack, Salesforce DevOps Center does not really compete with AutoRABIT, Blue Canvas, Copado, Flosum, Gearset, Opsera or Prodly.

Additional Industry Reactions

Industry leaders had plenty of reactions to Salesforce DevOps Center going GA. If there was a common chord in the chorus of replies, they supported the leadership Salesforce now provides for devops.

Kumar Chivukula, the CEO of Opsera, doesn’t seem worried about DevOps Center’s effect on their multi-SaaS, low-code approach to devops. “We do not see any immediate impact as the Salesforce DevOps Center offers basic functionality and only supports GitHub repositories. Our platform supports multiple source code repos (GitHub, Gitlab, Bitbucket) and both on-prem and SaaS. Plus, we have extensive integrations to various CI/CD tools, deeper orchestration capabilities across security, quality, compliance and ITSM services,” said Mr. Chivukula in email correspondence.

Prashanth Samudrala, the vice president of Products at AutoRABIT, emphasized the importance of developer and platform cybersecurity integration. “We are happy that Salesforce has finally acknowledged that source control is the way to go. But it does not stop there. Source control needs guard rails—these guard rails are extremely important for regulated industries that Salesforce DevOps Center overlooks. Essentially this new tooling replaces Salesforce change sets but does not address cybersecurity needs. We see DevOps Center as a net win for us because it brings more users into the DevOps ecosystem and as they mature, they’ll need tools like ours to support their evolving processes and address their security needs,” said Mr. Samudrala in email correspondence.

Gil Hoffer, the chief technology officer at Salto, believes that multi-SaaS is key to building business engineering solutions. “I view DevOps Center as a strong validation and confirmation by Salesforce that the DevOps approach is the correct way to manage SaaS Business Applications configurations. It will assist the whole ecosystem with market education and make the DevOps approach an unquestionable part of the way Business Applications teams work. But DevOps Center is still in its early stages and lacks many features and capabilities present in existing DevOps platforms. So, while it does present an immediate threat, the vendors have time to react. Eventually, it will commoditize basic capabilities, pushing DevOps vendors to go beyond simple deployment pipelines,” said Mr. Hoffer in email correspondence.

Kevin Boyle, CEO of Gearset, echoed these responses. “The release of DevOps Center represents Salesforce’s seal of approval on DevOps as the best approach to release management. Businesses still using Salesforce’s basic deployment offering, change sets, will now be exposed to DevOps — and begin considering how they can catch up with the trailblazers already practicing DevOps thanks to third-party solutions. DevOps Center will set development teams on the right path, but won’t support them all the way to implementing CI/CD. For complete DevOps support, businesses will continue to need the mature products in the market such as Gearset”, said Mr. Boyle in a statement.

More Coherent Salesforce Developer Tools for Trailblazers

Salesforce devops and release management occupies one of the the most advanced levels of knowledge and skill to which a Trailblazer can aspire. After all, Salesforce devops encompasses 11 separate categories of functionality. And it usually takes at least a decade of IT and business experience for one Trailblazer to have the skills a Salesforce devops practitioner needs.

Before DevOps Center Salesforce release management was murky at best, and usually required developer skills. Now, Salesforce DevOps Center provides automation that fills in important release management gaps. And with the Well Architected program and DevOps Center working in tandem, Trailblazers now have a better path for learning the skills to deploy impactful critical business applications.

Trailblazers Move Ahead with DevOps Center

David Clark from Prodly points out how DevOps Center opens release management to those Trailblazers with traditional admin skills.

“The impact will be largest for admins. DevOps Center gives them a point and click experience to manage a process that has been traditionally only managed by developers. This will require that they learn about managing a release pipeline, proper sandbox management and version control. As for experienced developers, DevOps Center will be a boon in that it will allow them to offload more work to admins in the development and release process. This enables a hybrid team model where admins and developers work alongside each other to build and maintain enterprise software,” added Mr. Clark in our email correspondence.

For some, though, dropping change sets will be daunting. Pablo Gonzalez from has some frank advice for experienced Trailblazers.

“This is like when Lightning was released to replace Classic. It was uncomfortable, and many of us threw a few tantrums, but now we’ve come to (mostly) accept it. Start looking at how to take advantage of DevOps Center or fall behind,” added Mr. Gonzalez in our email correspondence.

DevOps Center Moves Salesforce Devops Forward

With DevOps Center now formally part of the Salesforce platform, the industry consensus is we are in a new era of more coherent and better organized Salesforce release management. Before DevOps Center, performing release management required developer skills. Now, many more Trailblazers may strive for release management as an attainable skill.

The Salesforce DevOps Center story is all about improving Salesforce customers and the Trailblazer community. Outside of the integrations with and Prodly, DevOps Center currently has little impact on the ISV ecosystem. Larger enterprise customers and others with more advanced devops requirements will continue to develop in-house solutions or use Salesforce devops platform vendors. And DevOps Center should provide a funnel to platform vendors for those customers who need additional capabilities.

Finally, Salesforce has upgraded its developer messaging with coherent documentation about release management. Instead of being a problem for vendors, DevOps Center addresses one of the most enduring annoyances of Salesforce. Now Trailblazers have a better way to deal with the ugly XML which makes up Salesforce meta data.

But DevOps Center does more than just manage meta data. It is the glue between the Well Architected program, Salesforce DX capabilities, and low code developers. And developers and architects now have a clearer path to implementing a well-supported release management strategy. The best evidence of the company’s commitment to smoothing out release management is the new Salesforce DevOps home page.

So, it is with these high expectations that Salesforce DevOps Center finally launches after three years of expectations. The consensus is that DevOps Center will not clear the field of Salesforce devops platform vendors, but it will have a major impact on how most Salesforce customers approach release management. And the entire subject of devops is now taking center stage. Let us hope that 2023 ushers in new awareness of basic devops principles so we can move on to more complete devops management programs for everyone.