Salesforce DevOps Center : beta June’22

What is DevOps Center

Moving metadata between Sandbox and Production Orgs has never been easy, particularly for the declarative developer — i.e. the Admin. Change sets are a painful experience and replacing them has been long overdue.

Fortunately that wait is over. DevOps Center is the free replacement for Change Sets and it goes into public Beta in June with GA in the Fall. So we should expect some announcements at Dreamforce in September about GA and the roadmap.

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 goal of DevOps Center is to allow low code/no code declarative developers (Admins) to drive deployments in the same rigorous manner that pro-code developers (Developers) do, but with an easily understood point and click interface. There will then be just one single source of configuration and code that is managed in GitHub which will improve team collaboration and compatibility across all functions; admins, developers, release managers, QA, and business stakeholders.

The vision is that DevOps Center will support a unified deployment approach across Salesforce platforms — Lightning, Heroku, Mulesoft, Commerce, Marketing, and 3rd party ecosystem. The first release supports the Lightning platform and it has been architected to enable partners to build extension packages.

DevOps Center was announced at the TrailblazerDX session and was being demonstrated in the booth in the campground. There was no official recording of the session, but Salesforce gave us permission to record it on an iPhone at the last minute. Here is the slide deck that was presented.

3 core principles

As an Admin who is developing straight into production or using Change Sets to move metadata changes between sandboxes and production there will be a change to how you work. This is because the aim is to drive modern best practices like source control into the deployment approach. There are 3 principles that you need to understand.

DevOps Center Pipelines

This is the sequence of orgs that a change is pushed through from development to production. You may have several pipelines defined. A pipeline for high risk changes could be Dev (scratch or sandbox) — Test (sandbox) — Staging (sandbox) — Prod (production). Another might be for Hot Fixes which is just Dev — Prod. At Elements.cloud we have 4 different ones — 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 technical, business and regulatory risk. The lower the risk of the changes, the faster and cheaper it is to get into production.

In DevOps Center you define the Pipelines and link each stage to a different org.

DevOps Center Pipeline

DevOps Center Work Items and Bundles

When you are planning the work you define a Release that is made up of multiple User Stories. These are developed during the business analysis phase when you are understanding the business users’ requirements. The more rigorous the analysis, the better the User Story. More time spent here will reduce downstream rework and increase adoption because you are “Building the right thing”. This is the work before you complete before using DevOps Center.

In DevOps Center the Work Item is the same as a User Story. The Work Item is the collection of metadata that is being pushed through the pipeline. So a Work Item is the same as a Change Set, or part of it. A Change Set can sometimes be 100’s of metadata items because it is the Release. But with DevOps Center you can break the Release into a number of smaller, more manageable Work Items grouped together as a Bundle. In DevOps Center you group Work Items into a Bundle at a certain point in the Pipeline — i.e. Staging. So when you promote a Bundle it takes all the Work Items and promotes them at the same time. BTW a User Story could be related to multiple Work Items — the original Work Item and a new Work Item with changes to fix issues found in testing.

Currently you need to create a new Change Set and add all the metadata every time you push changes from org to org. You cannot simply copy it. Building Change Sets one metadata at a time is a massive time suck and source of constant frustration. And so many times the Change Set fails that you have to keep cloning it.

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

In DevOps Center when the Work Item is created and linked to a development org it creates a GitHub branch behind the scenes. You can then pull a list of all the metadata changes from that org and select them from the list to add to the Work Item. You do this once, as it is the Work Item that flows through the pipeline. This clean and easy way of populating a Work Item we believe will make the migration to DevOps Center a stampede.

DevOps Center showing a Work Item

GitHub Source Control

All the management of GitHub branches and moving metadata between branches and Salesforce orgs is managed by DevOps Center behind the scenes. GitHub is the central source control system but Admins do not need to understand GitHub and the CLI (Command Line Interface). Developers who are using CLI commands to manage GitHub will need to make a simple change to the command they use to commit changes so that DevOps Center is alerted to them.

Using GitHub is the biggest change for the Admin but it is important because it provides a consistent way of managing changes to Salesforce and enables better governance. It is forcing the adoption of development best practices, but with all the complexity hidden away.

The good news is that you can use the GitHub free tier.

Sounds too good to be true

DevOps Center is a deployment tool and the first release of the beta is in June. It is free and it has been built as the replacement for Change Sets. So yes. IT. IS. AMAZING.

But you need to understand the scope of DevOps Center. Think of it as an elegant way to drive changes through a deployment pipeline. It is not a sophisticated commercial DevOps tool with features like backup and rollback, testing, ticketing integrations and conflict checking.

However the architecture is in place to allow partner developed extensions. And the DevOps Center team has a clear view of the major roadmap items based on feedback from the pilot and closed beta users. Here are the current considerations.

• 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 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

Partner Extensions

The DevOps Center team has architected it so that partners can develop extension packages. Their expectation is that partners provide additional capabilities and integrations. The app is built in Heroku and is installed as a Managed Package. At time of writing it has 17 custom objects, 859 Apex classes, 15 Apex triggers and 80 Lightning Component Bundles. So it can be enhanced through an extension Managed Package. As the screens are not Lightning Pages there is no ability to drop in Lightning Web Components and that makes any UI based integration difficult.

The first partner extension is Elements.cloud that was launched at TrailblazerDX in the Salesforce DevOps Center session (recording is at the top of this post). The extension is already available and being used by the customers on the closed beta. The extension package is a low cost, limited scope implementation of Elements.cloud providing the support that DevOps Center to address some of the current limitations and extend the capabilities. For existing Elements.cloud customers it is a part of the core application, so is free.

The extension provides
- sync of metadata dictionaries with orgs, but you cannot see the metadata dictionary or dependency trees as this is not required for DevOps Center
- add and edit User Stories and the ability to link proposed metadata, existing metadata, process maps and documentation
- Elements — Jira integration
- the creation of Work Items linked to a User Story from Elements or Jira
- synchronization of Jira User Stories with Elements User Stories and DevOps Center Work Items
- the aggregated view of metadata across Work Items for conflict resolution and management of releases

DevOps Center with Elements.cloud right panel

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 their experiences and the DevOps Center data models and process maps that were developed to support the development.

What next

Start preparing for the open beta. That means getting an understanding of the 3 principles and how DevOps Center works. Then think through how that will be implemented inside your organization. There is an active Trailblazer Community Group sfdc.co/devops-tb. Plus to support you Salesforce and Elements.cloud are developing a DevOps Center Implementation Guide. The target is to get it out before the end of May, well before the open beta is available.

The contents of the guide are
- DevOps and DevOps Center principles
- DevOps tech architecture
- DevOps best practice
- DevOps operational processes
- Considerations when migrating from Change Sets
- Step by step implementation
- FAQ and training resources

Fill out the form here https://elements.cloud/app/doc/ and you will be emailed a copy of the guide when it is available (before end of May) so you can plan for the open beta.