Wave Goodbye to Change Sets: Hidden in the high profile announcements at TDX22 like Flow in Slack, Tableau, and RPA, there was a seemingly innocuous product launch that will have a far-reaching impact on the entire ecosystem. DevOps Center, which has been in development for 2 years, will be free in beta in June 2022 and GA in Fall 2022.
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
It is so significant because it enables the entire ecosystem to move to source-driven development at no cost. We estimate that there are 250k customers, and if we consider that 10k are using a commercial DevOps application or have written their own scripts, that leaves the rest either using Change Sets to migrate metadata or are developing straight into production.
Salesforce DevOps Center is free replacement to change sets
DevOps Center will replace Salesforce change sets for free. “This is going to make my life exponentially easier,” said an admin when the annoucement was made on the Trailblazer Group. Those who battle change sets every day know that they are painful, frustrating, and time-consuming.
DevOps Center provides a point and click interface to move metadata between orgs. The fundamental difference to change sets is that it introduces source-driven development and a UI that makes the management of metadata easy. DevOps Center uses GitHub for source code control but hides the complexity so that is is easy for Admins to migrate.
This brings the development approach of the Admin (declarative/lowcode) closer to the Developer (pro-code). Developers use CLI and scripts to move metadata. The underlying benefit is all stakeholders – admins, developers, release managers, QA, and business stakeholders – are working on a single set of configuration and code. ThIs will improve DevOps practices and team collaboration.
Admins will need to modify the way they work if they are either developing straight into production, or using change sets. The feedback from the customers using DevOps Center in the pilot and closed beta is that migrating to DevOps Center was such a revelation and that the adtoption of it is a no-brainer.
“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
Even more interesting is that the long-term vision for the DevOps Center is to support a common deployment approach for all the applications in the Salesforce platforms: Lightning, Heroku, Mulesoft, Commerce, Marketing, and presumably Slack.
DevOps Center – under the hood
The first public sighting of DevOps Center was at TrailblazerDX ‘22. There was a session that gave an overview of DevOps with Marcus & Millichap, a customer from the closed pilot, and Elements.cloud who has developed the first partner extension. Salesforce didn’t record the session, but at the last minute Salesforce gave permission to record it on an iphone. Here is our recording and the slide deck that was presented. A full demo/webinar is planned.
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, and 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.
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. As DevOps Center is a Managed Package,
The DevOps Center team designed it so partners can develop extensions to extend the functionality and overcome some of the current limitations. The feedback from the pilot and closed beta users has given the DevOps Center product team the roadmap items and priorities.
Under the hood, DevOps Center is complex as you can see from the data model below. DevOps Center is on the left and Elements.cloud partner extension is on the right. You can see the key point of integration is the Work Item. But more on this later.
Salesforce DevOps Center terminology
First we need to establish some terminology for DevOps Center. Much of this is DevOps best practice and not specific to DevOps Center. Here are different terms 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 and sandbox orgs through to production.
- Pipelines and Stages: These are the sequence of orgs (stages) that the work item is pushed (promoted) through to production. You can define different pipelines.
- 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 the Development phase (comparing DevOps Center with Change Sets):
All metadata changes should be grouped into a release, no matter how big or small. A new app could have 100’s of metadata items, or a hotfix might have only 1 or 2 metadata items. DevOps Center does not manage releases. So they are created and managed using an app like Elements cloud in context of the business requirements. A release has one or more user stories.
A user story defines the development work but it will provide the development team with more than a list of metadata items. It will have the business analysis documentation. This will wil ladd context and reduce the ambiguity for the developemnt team. This eliminate costly rework and frustration and ultimtely increase user adoption.
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 contains the list of metadata items that are pushed through a pipeline. As you can see from the data model this is the pivotal object. In fact it is the only object that is really exposed to the Admin.
A user story can create and link to one or more work items. There is only one work item link to a user story unless there is a fix to the metadata items attached to a work item. In this case a new work item needs to be created as in DevOps Center you cannot reopen the original work item.
There is no visibility inside DevOps Center or the relationships between work items, so the only polace is the only user story.
The work item has eliminted the 2 largest issues with change sets.
- When you create a change sets you add each the metadata item one by one. A new change set needs to be created to push changes between orgs; Dev to UAT, and another identical one to go from UAT to Prod. Three is no option to copy a change set with all the metadata items. WIth DevOps Center you create a work item and it lists the metadata items that need to be added and you select them from the list.
- A change set can get big with 100’s pof metadata items because it is a release. With DevOps Center 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, youneed to link it to the development org in Salesforce. A GitHub branch is automatically created by DevOps Center.
When the develop is ready to push the changes, you can get the list of metadata items in that developer org since the last commit. You select them from the list to add to the work item. This one feature will have Admins begging to use DevOps Center. BTW did I say that you do this just once, as it is the work item that flows through the different stages of the pipeline.
Pipelines, Stages and Projects
You define the pipelines based on the orgs that your metadata changes flow through from development to production. The work item is pushed through the pipeline with metadata items attached.
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.
You can have multiple pipelines, each in a separate DevOps Center project. It depends on how sophisticated your development processes are. You might just have a core process and a hotfix. At Elements.cloud we are able to assess the risk of changes and allocate them to one of four different pipelines – High, Medium, Low and Hot Fix. Wen can apply the right development and testing resources to a release based on its technical, business, and regulatory risk.The lower the risk the changes are put through a faster (and cheaper) pipeline. We can do this because we use Elements.cloud and are able to understand the risk of changes by looking at all the metadata and dependencies and the business processes that are impacted.
A key benefit of splitting releases into work items is they are easier to manage. But you need to bring them all together in one of the final stages of the pipline – a budled stage. When you promote any work item from a bundled stage, all the other work items in that stage are promoted them at the same time.
You need to be careful when you define pipelines. If the same stage is marked as “bundled” in different pipelines, then all work items in that stage in all the pipelines will be promoted.
Source Control and GitHub
DevOps Center manages GitHub including creating new branches, moving metadata between branches, and moving metadata between Salesforce orgs. Admins do not need to understand GitHub, source control and the CLI as the comlexity is hidden. Whilst this simplifies DevOps for Admins, however it is worth understanding the principles of DevOps. A good source is the Gearset Launchpad training. https://devopslaunchpad.com/
There are many source control systems however, in the initial release of DevOps Center it is integrated with GitHub. The good news is that you can use the GitHub free tier. BitBucket is on the roadmap as the next source control system to be supported.
DevOps Center: Limitations & Partner Extensions
DevOps Center is not a full DevOps product. It does not have metadata backup and rollback, testing, ticketing integrations and conflict checking. It is an elegant deployment tool ties to source xontrol that is easy to implement and free.
There are some limitations that need to be considered when planning the migration. Allowing partners to develop low-cost extensions that eliminate many of the issues that could prevent widescale adoption. Here are the current limitations of DevOps Center.
- Org-based development The DevOps Center approach is org-based rather than package-based development (DX). The vast majority of the Salesforce ecosystem. are using org-based development.
- Jira interation There is no integration with Jira to keep Jira user stories in sync with DevOps Center work items. This is resolved with the Elements partner extension.
- Metadata conflcts 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. Assessing the risk of promoting work items is dififcult and there are sevreal uses caes isted below. These are resolved with the Elements partner extension.
- Resolving Github errors: 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.
- Bundled stages: When different pipelines have the same stage set as bundled and the pipelines are in different projects, if you promote a work item with metadata in one pipeline it will promote all the work items in the different pipeline that are not ready to be promoted.
- Multiple work items with same metadate: 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
Whilst thse issues seem show stoppers, change sets don’t alert you to conflicts. The change set simply overwrites the metadata and any earlier changes. You only find out the issue in production when the org breaks.
DevOps Center, GitHub, and source control, will enable more robust metadata management practices.
DevOps Center with Elements is the first partner extension, launched at TrailblazerDX ‘22. The Elements team is already sharing our experience with other partners. We also developed the DevOps Center data models and process maps that were needed to develop the extension.
The Elements 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 proven with closed beta customers.
It provides the management of release and user stories, integration of Jira user stories, and the linkage back to DevOps Center work items. Hence it provides the critically important conflict checking at release, user story and work item.
This diagram explains the interactions and flow of data between Elements.cloud, Jira, DevOps Center and GitHub:
The extension provides:
- Manage releases with user stories.
- Manage user stories with links to risk scoring, documentation, notes, images, URL links, process maps, ERD, Jira tickets.
- Elements-Jira integration.
- Manage work items linked to a user story from Elements or Jira.
- Manage metadata dictionaries synced to orgs, but no access to the metadata dictionary or dependency trees.
- Sync Jira user stories, Elements user stories, and DevOps Center work items.
- Provide metadata conflict resolution across releases, users stories and work items
In the image below you can see the Elements right panel. The different tabs (vertical icons) organizes the information captured during business analysis; info, risks, new and changes metadata, DevOps, documentation and collaboration. The new DevOps 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 to Salesforce Setup to look at the metadata items.
Migrating to DevOps Center
Now is the time to start planning for DevOps Center as it will be available in open beta in June 2022 and to get the best out of it it requires a little planning. Developers simoply need to make a smal change to the command then make to commit changes. Admins have a bigger change as they need to understand how to use DevOps Center. But the time saving over change sets will make the decision to move easy. The customers who have been on the pilot and closed beta have seen huge benefits.
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 migration to DevOps Center is an opportunity to streamline and improve your dev ops processes. Using better impact analysis of changes means you can categorise the risk of the changes and then allocate the right level of development and testing. Low risk changes can be into production in hours. High risk changes are less likely to blow up the org.
To help you plan a DevOps Center Implementation Guide is in development with input from Salesforce, Elements.cloud and the pilot customers. It will include a step by step implementation advice, considerations when migrating from change sets, best practices, example devops processes and more.
Join the active Trailblazer Community Group.
Register here to be sent a copy of the guide when it is available.