Follow and complete a Learn MOAR Winter ‘23 trailmix for admins or developers by November 30, 2022, 11:59 p.m. PT, to earn a special community badge and enter for a chance to win one of five $200 USD Salesforce Certification vouchers. Restrictions apply. Learn how to participate and review the Official Rules by visiting the Trailhead Quests page.
DevOps Center is our new product that greatly improves the change and release management process when developing with Salesforce. It allows entire teams to take advantage of modern DevOps best practices, whether they choose to use the new DevOps Center click-based user interface or existing modern tooling like the Salesforce CLI or IDEs.
Why DevOps Center is great for teams
DevOps Center is built upon the same foundation as our SFDX CLI. This means that DevOps Center utilizes the same SFDX project, commands, and general principles that have been introduced over the years with Salesforce DX. More importantly, this also means that DevOps Center is compatible with methodologies being used with Salesforce DX. This is a significant improvement over change sets, which are basically incompatible with the SFDX CLI and source-driven development in general.
So now, entire teams can take advantage of modern capabilities, such as source-driven development, use of source control, and automation, but using the tools of their choice. They may use command-line interfaces like the CLI, IDEs like VS Code or Code Builder, and GitHub, OR a declarative UI/click-based interface. We call these types of teams “hybrid teams,” and as we’ve been developing DevOps Center, it’s been one of our goals to deliver a robust experience for them.
Who’s on the team?
In designing DevOps Center, we’ve been focused on a few key user personas for whom we’re working to deliver a robust end-to-end change and release management experience:
- DeeDee — a Declarative Developer, or Admin, using primarily low-code and click-based tooling to do her development
- Pedro — a Programmatic Developer, using more pro-code methodologies, including the Salesforce CLI and Source Control
- Romeo — a Release Manager, who may be using either click-based interfaces or command-line interfaces to perform deployments
Example hybrid team use cases
Let’s look at a few common use cases that highlight how these hybrid teams can come together through the use of DevOps Center.
Use case #1: DeeDee contributes her changes to a shared project repository using a declarative/UI-based interface
This is one of the most common team struggles that we hear about today.
The current situation:
A portion of the team has adopted source-driven development practices and is using a source control repository to manage their metadata source. The declarative developers on the team are using change sets to manage their changes. All of these changes, whether through source control or change sets, end up in the same test and production orgs.
Challenges with the current situation:
The change set-managed metadata never gets into the source control repository since the declarative developers’ process does not provide an interface that makes it easy for them to get their changes into the repository. Therefore…
- The repository doesn’t actually reflect all the changes for the entire team
- Conflicts are hard to manage
- It’s hard to understand what is going into the release.
DevOps Center to the rescue:
With DevOps Center, DeeDee can commit her changes to the same source control repository that the team uses by using simple clicks. She can even create a Pull Request in GitHub with the click of a button in DevOps Center, signaling to others on the team that her change is committed and ready for review. When Pedro or someone else on her team reviews and approves the change, it can be marked “Ready to Promote” in DevOps Center, making it available for promotion (deployment) by Romeo (or DeeDee herself, depending on the team’s governance process) to the shared test orgs in the pipeline.
DeeDee can now work within DevOps Center using clicks and her changes are managed in the team’s centralized source control repository. Therefore…
- The repository is inclusive of the entire team’s work
- Conflicts can be identified earlier
- There is increased visibility of the changes going into the release
- The team achieves enhanced governance and change management
Use case #2: Pedro and DeeDee contribute to the same project, but Pedro wants to use the CLI and IDE, and DeeDee wants to use a click-based declarative interface. AND they want visibility into each others’ changes.
This is similar to use case #1 from the DeeDee perspective, but this use case adds the scenario that Pedro is doing his own development through his existing CLI and IDE-based methodologies. With DevOps Center, everyone can have visibility into what is going on with the project and the changes that are being made.
How the DevOps Center project model facilitates collaboration
The DevOps Center project is associated with a repository on GitHub. This is the same project repository that the whole team uses to manage the metadata source. The DevOps Center project also contains a pipeline that defines the stages that the changes go through from development, testing, and production. Each of these stages is associated with a Salesforce org, as well as a branch in the source control repository. DevOps Center also uses “work items” as the primary object to define the changes to be made and to track them throughout the lifecycle. Each work item has an associated feature branch in the repository. This feature branch is created automatically by DevOps Center when the work item is started, and the name of the branch matches the ID of the work item (ex: WI-00001).
So, the key to making this use case work is to ensure that the branches that Pedro is working against in the source control system are aligned to the branches that the DevOps Center project is set up with (or vice-versa). Changes that are made in the source control repository to any of the branches that DevOps Center knows about will be reflected in DevOps Center.
Let’s look at a typical workflow to see how this works.
1. Start work
Pedro picks up his work item in DevOps Center. He selects the option to “…develop and commit my changes to the work item feature branch from outside of DevOps Center.” This puts the work item into the “In Progress” state AND creates a feature branch in the repository with a name that matches the work item. Pedro could alternatively just create the branch in the repository himself, but it must have the same name as the work item in order for the synchronization to work properly.
2. Make changes in IDE and commit changes to feature branch in the repository
Now Pedro can make his changes however he likes. For instance, he could use VS Code with Salesforce extensions, or the new Code Builder — a web-based IDE that provides the same capabilities as VS Code, but in an easy-to-setup, web-based interface. He checks out the feature branch for the work item, makes his changes, and then commits those changes to the work item’s feature branch.
Now, if someone were to look at this work item in DevOps Center, they will see the commit that Pedro just did. It will also show the files that were part of the commit. Slick!
3. Create Pull Request
Now when Pedro is ready to create a Pull Request to initiate a review and merge his changes into the next stage branch, he can do this directly from GitHub, the IDE, or CLI as desired. The Pull Request should be created between the work item’s feature branch to which he has been committing his changes, and the branch that corresponds to the first stage of the pipeline. In our example below, this is the integration branch.
After Pedro creates this Pull Request, his teammates can see in DevOps Center that the work item is “In Review,” and they have easy access to the Pull Request directly from the work item. How’s that for facilitating team collaboration?!
4. Merge the Pull Request
Once the Pull Request is reviewed and approved, someone on the team may choose to merge it directly from GitHub.
Now in DevOps Center, the team can see that the changes have been merged “externally,” or from outside of DevOps Center. And since the Promotion step in DevOps Center performs both the merge and deployment, because the work item has now been merged, it tells the user that the changes must now be deployed in order to keep the integration branch and org in synch with each other.
5. Complete the promotion of the work item
In the currently available Open Beta release of DevOps Center, the deployment must be completed from within DevOps Center. In the GA timeframe, we will be delivering a CLI plugin that allows for the deployment to be performed via the CLI, and therefore from outside of DevOps Center as desired. This will allow the entire flow to be performed either inside of DevOps Center, outside of DevOps Center, or through a combination of both!
Get DevOps Center now!
DevOps Center is currently available in open beta and can be enabled and installed in any production org with a Professional, Enterprise, or Unlimited edition. It’s also available in Developer Edition and Trailhead playground orgs. For information on how to enable, install, setup, and use DevOps Center see:
For more information, video demos, and to be part of the conversation, visit our DevOps Center Trailblazer Community Group.
See these new features in action!
Don’t forget to watch the Winter ’23 Developer Preview on September 22 during Release Readiness Live to see demos of a subset of these new, exciting features. And if you’re attending Dreamforce, join us LIVE! Be sure to check out the Learn MOAR Winter ’23 for Developers Trailmix and follow along on the blog this week for more Learn MOAR!
About the author
Karen Fidelak is Sr. Director of Product Management for DevOps Center at Salesforce. When not working to bring great products to the Salesforce developer community, she enjoys exploring the great outdoors in her beautiful home state of Colorado.