Salesforce DevOps Center is the place to manage releases and to give low-code and pro-code development team members a single set of configuration and code to work with bringing closer collaboration. It is the free replacement for change sets, enabling everyone to deploy changes using an elegant point-and-click interface.
DevOps Center will be free for all Salesforce customers in an effort to support every organization as they put DevOps best practices in place, including releases, user stories, pipelines, work items, and source control.
After circulating the news streams and rumor mill, the wait is finally over. DevOps Center is set to go into public beta in June 2022, and General Availability (GA) in the fall (autumn) of 2022.
This guide is based on our experiences during the closed beta and working with the DevOps Center team on the partner extension approach. Some of the terms mentioned may be new to you – but don’t panic. The aim is to help you understand each of them in the context of DevOps Center (while relating back to how life works with Change Sets), so you will have more confidence to start planning for the open beta.
What is Salesforce DevOps Center?
DevOps Center will bring the declarative/low-code/no-code developer (admins) and the pro-code developer (developers) closer together. This means that they can work with a single set of configuration and code while applying DevOps best practices. This will also improve team collaboration and compatibility across all functions – admins, developers, release managers, QA, and business stakeholders.
“DevOps Center is all about change and release management and introducing DevOps best practices to our entire community, regardless of where you fall on the low-code to pro-code spectrum” – Karen Fidelak, Salesforce DevOps Center Product Manager
The aim of the Salesforce DevOps Center is to drive modern best practices, like source control, into the deployment approach.
Pro-code developers have always been comfortable using the command line interface (CLI), as well as writing scripts to commit changes to a source control system like GitHub.
DevOps Center will provide the same power to admins, with the complexity of GitHub hidden behind an easily understood declarative UI.
There will be a change to how you work if you are either developing straight into production, or using change sets to move metadata changes between sandboxes and production. But the benefits of adopting DevOps Center are overwhelming according to the closed beta customers.
Wave Goodbye to Change Sets
The DevOps Center will replace Salesforce change sets. Almost all development teams share the same sentiment about change sets – they are painful, frustrating, and time-consuming.
The alternatives currently available have been writing your own scripts, purchasing a third-party DevOps application, or developing straight into Production (eek!).
“This is going to make my life exponentially easier” – said one admin when they heard DevOps Center was going into public beta.
Salesforce DevOps Center Availability
The Salesforce DevOps Center release is a big deal. It has been highly anticipated because it has been in development for 2+ years – first with pilot customers, followed by a larger set of customers in the closed beta. Their experiences have been fed into the development roadmap.
DevOps Center was announced and demoed at TrailblazerDX ‘22. While there wasn’t an official recording of the session, Salesforce did give us last-minute permission to record. Here is our recording and the slide deck that was presented.
Salesforce has to strike a balance between delivering all the functionality that customers could want, and getting the first release into General Availability (GA). The public beta is in June 2022 and GA in the Fall 2022, so we should expect some announcements about the GA release and the roadmap at Dreamforce (September 2022).
As DevOps Center is a Managed Package, it is not tied to any of the three major platform releases per year, which gives the team more flexibility in launching it and providing updates.
The first release supports the Lightning platform and it has been architected to enable partners to build extension packages.
The long term vision for the DevOps Center is to support a unified deployment approach across the Salesforce platforms: Lightning, Heroku, Mulesoft, Commerce, Marketing, and the third-party ecosystem.
How Salesforce DevOps Center Works [Data Model]
First, let’s define the different elements involved in Salesforce DevOps Center and the relationships between them:
- Releases: Any set of changes will be grouped into a release. A release is split into one or more user stories.
- User Stories: These are defined during the business analysis phase in collaboration with the end users. A user story is related to one or more work items.
- Work Items: These contain the list of metadata items that are being changed. You create that list just once (unlike change sets which have to be recreated for every move between orgs). The item is pushed through the pipeline stages from dev orgs through to production.
- Pipelines and Stages: These are the sequence of orgs (stages) that the work item is pushed (promoted) through from dev to prod. You can define different pipelines e.g. “core” and “hotfix”.
- Bundled Stages: One or more stages in the pipeline can be marked as “bundled”. At this point, all work items in that stage are promoted at the same time to the next stage.
- Source Control: Behind the scenes, DevOps Center manages all GitHub branches, including moving metadata between branches, and Salesforce orgs. GitHub is the only current source control system supported.
Here is a data model of the relationships in the Business Analysis phase of work and Development phase (comparing DevOps Center with change sets):
All metadata changes should be grouped into a release, no matter how big or small – from the first release of a new app into a Salesforce org (which contains hundreds of metadata items), through to a hotfix (with only one or two metadata items).
Releases are created and managed outside of the DevOps Center and are created in the context of the business requirements. A release has one or more user stories.
A user story defines the scope of the development work. It will be more than just the metadata items that will be created and changed. It will also have all the information captured during the business analysis phase that will make it easier for the development to be completed easily and accurately. This additional information will add context and eliminate costly rework due to miscommunications.
User story information will include:
- The Release it is assigned to.
- Notes and specifications.
- URL links to videos and documents.
- Images such as wireframes, diagrams, and photos of whiteboards.
- Business process maps (UPN), capability diagrams, and flowcharts.
- ERDs (Entity Relationship Diagrams).
- Salesforce Architect diagrams.
- The specific roles impacted.
- Technical, business, and regulatory risk assessment.
- Link to the Jira ticket (if Jira is used to manage the development work).
User stories are also created and managed outside of the DevOps Center.
In DevOps Center, the work item is the same as a user story, containing the list of metadata items that are pushed through a pipeline.
A user story can create and link to one or more work items. Normally it will link to one work item, but if there is a fix to the metadata items attached to a work item, then a new work item needs to be created (because you cannot reopen the original one).
The user story is where you see the relationship between these two work items as there is no visibility inside DevOps Center.
Historically, you had to create a new change set and add all the metadata every time you pushed changes between orgs – one change set to push from Dev to UAT, and another change set to go from UAT to Prod (even though it is the same metadata list). You could not simply copy a change set with all the metadata items, which means that change sets are a massive ‘time-suck’, as well as a source of constant frustration.
“With change sets, you are ecstatic if it goes through the first time. With DevOps Center you are disappointed if it doesn’t.” – John Eichsteadt, Platform Owner, Marcus & Millichap
Plus, a change set can sometimes contain hundreds of metadata items because it is effectively a release. Going forward, in DevOps Center, you can have multiple work items, which make up a release; therefore, you can break the release into a number of smaller, more manageable work items.
In DevOps Center, when the work item is created from the user story, you link it to a Salesforce org. Behind the scenes, DevOps Center creates a GitHub branch.
You can then pull a list of all the metadata changes in that Salesforce org and select (from the list) which you’d like to add to the work item. This is so much faster than building a change set, metadata item by item at a time.
You do this once, as it is the work item that flows through the pipeline. This is a clean and easy way of populating a work item – and something that we believe will make the migration to DevOps Center a no-brainer.
Pipelines, Stages and Projects
Pipelines are the flow of work items (i.e. metadata changes) from development to production.
A pipeline has a series of stages – each stage related to a Salesforce org. A stage could be a scratch org or sandbox org for development. It could be a sandbox for UAT or staging. And the final stage will be production. A work item is “promoted” from one stage to the next in the pipeline.
DevOps Center allows you to have multiple pipelines, each in a separate DevOps Center project. For example, we have four different pipelines – High, Medium, Low and Hot Fix. This enables us to allocate the right level of development and testing resource to any release, based on its risk – technical, business, and regulatory. The lower the risk of changes, the faster (and cheaper) it is to get into production. We are able to understand the risk of changes by looking at all the metadata and dependencies, plus the business processes that are impacted in Elements.cloud.
You can define any stage in the pipeline as “bundled”. When you promote any work item in a bundled stage, it takes all the other work items in that stage, and promotes them at the same time.
If that same stage is marked as “bundled” in different pipelines, then all work items in that stage in all the pipelines will be promoted. Careful consideration is required when designing pipelines – to start with, keep it simple by having a core pipeline, and a hotfix pipeline.
Behind the scenes, DevOps Center manages all GitHub branches, including moving metadata between branches, and Salesforce orgs.
GitHub is the central source control system – however, Salesforce Admins do not need to understand GitHub and the CLI (DevOps Center shields you from this). Source control is perhaps the biggest change for Admins – but with all the complexity hidden away.
Developers using CLI commands to manage GitHub need to make a simple change to the command they use to commit changes, so that DevOps Center is made aware of the changes. This is important because all changes to configuration and code need to be managed in the same source control system, across the different collaborators.
The good news is that you can use the GitHub free tier.
DevOps Center: Scope and Limitations
DevOps Center is a free deployment tool that has been built to replace change sets – so yes – it is amazing!
Scope and opportunity
However, DevOps Center is not a fully-fledged DevOps product* with features such as backup and rollback, testing, ticketing integrations and conflict checking. Instead, think of it as an elegant way to drive changes through a deployment pipeline with the metadata management source control in GitHub.
*third-party, paid solutions.
The DevOps Center architecture is in place to allow partner-developed extensions to support broader use cases. The DevOps Center product team has a clear view of major roadmap items, based on the feedback from the pilot and closed beta users.
- Initially, DevOps Center will only work with GitHub. If your developers are using another source control system (e.g. BitBucket), then they will need to change to GitHub, or wait until a later release of DevOps Center. Using two different source control systems is a recipe for disaster. Support for BitBucket has been identified as a major roadmap item.
- The DevOps Center approach currently supports org-based development, rather than package-based development (DX). Org-based development is the current approach adopted by the vast majority of the Salesforce ecosystem.
- There is no integration with Jira, the most popular ticketing system, to keep Jira user stories in sync with DevOps Center work items.
- There is no ability to see if a metadata item is in different work items in the release in the same pipeline, or in different releases across different pipelines. This makes assessing the risk of promoting work items challenging.
- This makes resolving Github errors difficult, e.g. the most common rebase error which is thrown up when a work item cannot be promoted because it needs changes that are in another work item.
- This is even more critical when different pipelines have the same stage set as bundled because the pipelines are in different projects. Promoting a work item with metadata in one pipeline will promote work items in a different pipeline that are not ready to be promoted
- If multiple work items are related to the same metadata – e.g. fixing a bug, then the original work item could be promoted by mistake instead of the new work item that fixes the bug
You may not know that these conflict issues already occur when using change sets – however, you never realize because a change set simply overwrites the metadata rather than flagging a conflict (you only find out when the org breaks). So by using DevOps Center, GitHub and source control, you will put more robust metadata management practices in place.
Overcome Limitations with Partner Extensions
The app is built on Heroku, and is installed as a Managed Package. This means that it can be enhanced through an extension Managed Package.
At time of writing it has 17 custom objects, 859 Apex classes, 15 Apex triggers and 80 Lightning Component Bundles. As the screens are not Lightning Pages there is no ability to drop in Lightning Web Components which makes any UI based integration challenging.
The good news is that partners are able to extend DevOps Center to resolve many of these issues.
DevOps Center with Elements
DevOps Center with Elements is the first partner extension, launched at TrailblazerDX ‘22.
The extension package overcomes most DevOps Center limitations that will hinder wide-scale adoption, and will be priced affordably. It’s available now, and has been used by closed beta customers.
The extension provides:
- Create metadata dictionaries synced to orgs, but no access to the metadata dictionary or dependency trees.
- Create releases with user stories.
- Create user stories with links to risk scoring, documentation, notes, images, URL links, process maps, ERD, Jira tickets.
- Elements-Jira integration.
- Create work items linked to a user story from Elements or Jira.
- Keeping Jira user stories, Elements user stories and DevOps Center work items in sync.
- Aggregated view of metadata across work items for conflict resolution and management of releases.
In the image above you can see the Elements right panel. The different tabs accessed by the vertical icons provides access to all the information captured during business analysis. The new DevOps Center tab shown here has the different Work Items that are related, and also all the metadata items across those Work Items for conflict resolution. Links in this panel can also take you to the main Elements app to look at the Release and User Story, to the Jira ticket, or Salesforce Setup to look at the metadata items.
This diagram explains the interactions and flow of data between Elements.cloud, Jira, DevOps Center and GitHub:
If other partners want to develop extensions, the Elements team is very happy to share our experiences, plus the DevOps Center data models, and process maps that supported the development.
Start preparing for the open beta by ensuring you understand the DevOps Center principles. Think through your business analysis and development processes, as some organizations will need to make changes.
Join the active Trailblazer Community Group.
To further support your planning, Salesforce and Elements.cloud are developing a DevOps Center Implementation Guide, which will include a step by step implementation advice, considerations when migrating from change sets, and more.
Register here to be sent a copy of the guide when it is available.