With DevOps Center, teams can improve 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 DevOps Center’s click-based user interface or existing modern tooling like the Salesforce CLI or IDEs.
In this blog post, we’ll explore two common declarative and programmatic use cases, and then walk through a DevOps Center workflow that brings the two together.
Why DevOps Center is great for teams
DevOps Center is built upon the same foundation as our Salesforce CLI. This means that DevOps Center utilizes the same Salesforce DX projects, commands, and general principles that have been introduced over the years. 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 incompatible with the Salesforce CLI and source-driven development in general.
Now, entire teams can take advantage of modern capabilities, such as source-driven development, use of source control, and automation, and use 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, including:
- DeeDee: A declarative app 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
- Ramya: A release manager who may be using either click-based interfaces or command-line interfaces to perform deployments
Common use cases
Let’s take a look at a few common use cases that highlight how these hybrid teams can come together using DevOps Center.
Use case #1: Contributing changes to a shared repository using declarative interface
In this use case, DeeDee contributes her changes to a shared project repository using a declarative/UI-based interface. This is one of the most common team struggles we hear about today.
The current situation
A portion of DeeDee’s 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 with 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 Ramya (or DeeDee herself, depending on the team’s governance process) to the shared test orgs in the pipeline.
Benefits
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: Gaining visibility into changes made via code and no-code methods
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 DeeDee’s 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, to testing, to 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 (for example: 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.
Now that we understand how the DevOps Center project model facilitates collaboration, let’s explore a typical workflow.
A typical DevOps Center workflow
Pedro, who prefers using the CLI and IDE, uses DevOps Center to ensure that his feature branch is in sync with the project, just like DeeDee’s click-based changes.
Step 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.
Step 2: Make changes in IDE and commit changes to feature branch in the repository
Pedro can now make his changes however he likes. For instance, he could use VS Code with Salesforce extensions, or the new web based IDE, Code Builder, which provides the same capabilities as VS Code, but in an easy-to-set up, 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!
Step 3: Create a pull request
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 status is In Review, and they have easy access to the pull request directly from the work item. How’s that for facilitating team collaboration?!
Step 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.
In DevOps Center, the team can now see that the changes have been merged “externally,” or from outside of DevOps Center. The Promotion step in DevOps Center performs both the merge and deployment, and 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 sync with each other.
Step 5: Complete the promotion of the work item
The deployment can be completed from within DevOps Center or “externally” using the Salesforce CLI. The new DevOps Center CLI plugin includes a sf project deploy pipeline command (currently in Beta) that provides a programmatic interface to perform deployments that are compatible with DevOps Center.
The release manager Ramya (or Pedro himself, depending on the team’s governance process) can use the Salesforce CLI to deploy to the shared test orgs in the pipeline. She can specify the branch name, username, and project name in the command line arguments.
sf project deploy pipeline start --branch-name integration --devops-center-username ramya@example.com --devops-center-project-name TestDemo1
Additionally, Ramya can perform a validate-only deployment before deploying to the staging or release environment using the following command:
sf project deploy pipeline validate --branch-name staging --devops-center-username ramya@example.com--devops-center-project-name TestDemo1 --bundle-version-name 1.0.1
This validation runs Apex tests to verify whether a deployment will succeed without actually deploying the metadata to your environment. This allows you to quickly deploy the changes later without re-running the tests using:
sf project deploy pipeline quick --devops-center-username ramya@example.com --use-most-recent
She can also check the status of a pipeline deploy operation from the command line using:
sf project deploy pipeline report --devops-center-username ramya@example.com --use-most-recent
Note: sf project deploy pipeline commands are currently in Beta.
This flexibility allows the entire flow to be performed either inside DevOps Center, outside DevOps Center, or through a combination of both. Everything stays in sync and is visible to the entire team. This can also integrate with your CI/CD pipeline!
Get DevOps Center now!
DevOps Center 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, set up, and use DevOps Center, see:
For more product information and demo, visit our product page.
About the authors
Tara Venkatesan is a Product Marketing Manager for Salesforce Data Cloud. She focuses on platform integrations, segmentation, and activation.
Satya Sekhar Chegondi is a Lead Developer Advocate at Salesforce focusing on Lightning Web Components and developer tools. He is passionate about sharing his knowledge about all possible with the Salesforce Platform with various audiences in an understandable format. You can follow him on X.