Features of Salesforce DevOps Center
With DevOps Center, you’ll have access to the following new features:
DevOps Center features an easy-to-use UI that allows declarative and programmatic users to work side-by-side. It reflects changes regardless of whether you’re moving them from a CLI or from within the point-and-click DevOps Center app.
Automatic Change Tracking
DevOps Center provides a modern, easy-to-use change tracking experience throughout the lifecycle process. Changes are automatically tracked and listed in the UI, so you don’t have to manually keep track of them anymore.
In DevOps Center, a release pipeline defines the sequence of stages that work items progress through as they go from development to production. You can define the number of stages you want in your release pipeline when you configure DevOps Center. Each stage should correspond with a sandbox or org where the work of that stage takes place.
DevOps Center allows your team to easily collaborate and communicate at each stage of the release pipeline. You can also hit “Review” so others can either approve your work or send it back for more modifications.
Robust Source Control
Because DevOps Center is integrated with GitHub, there’s one single source of truth for all your code changes, whether they were made programmatically or declaratively. However, because DevOps Center only handles metadata, configuration data changes aren’t supported.
DevOps Center manages all GitHub branches and seamlessly orchestrates changes between source control branches and orgs. It migrates metadata between environments and branches across your project pipeline.
*Note that declarative users do not need any knowledge of GitHub. DevOps Center applies Salesforce’s “clicks, not code” approach to the complexity of source control.*
Programmatic users who use CLI commands only need to leverage a slightly adjusted command to alert DevOps Center to any changes.
Eventually, DevOps Center will integrate with multiple third-party source control systems, including not just GitHub, but also Bitbucket and GitLab.
User Stories That Define the Scope of the Work
A user story is related to one or more work items and delineates the work you want to perform. It encompasses the metadata items you’ll create and change. It also includes all the information recorded in the business analysis phase to provide additional context. This helps prevent errors and streamlines the process.
Work Items to Define the Scope of the Work
A work item is a ticket that forms a fundamental part of the overall data model. You use work items in DevOps Center to track the progress of the changes you’ve made to accomplish a specific goal, such as fixing a bug or enabling a user story. Work items help yWork items that define the scope of the changes
A connection to a version control repository that stores changes for the project
The environments you’re using to make changes
The environments you’re using for the vour development team identify the status of changes and manage their progress. This makes it easier to coordinate a release.
Projects That Let You Manage Changes
A project allows you to manage all the changes you’re making for a specific application. It encompasses configurations and definitions of all the aspects involved in managing a set of changes, including:
- Work items that define the scope of the changes
- A connection to a version control repository that stores changes for the project
- The environments you’re using to make changes
- The environments you’re using for the various pipeline stages like integration, UAT, and staging
- A configurable, click-based deployment pipeline that defines how changes are migrated from environment to environment on their way to production. For example, you can set up a hotfix pipeline. You can also establish long-term and short-term project pipelines.
Work Item Bundles to Effortlessly Manage Releases
Rather than wading through a list of metadata components to make a change set, DevOps Center simplifies managing releases. When you configure a pipeline, you’ll define a bundling stage. When changes progress to this stage of the pipeline, you bundle them together. You manually select them and move them as a bundle or unit instead of selecting individual work items for promotion.
In DevOps Center, you can determine who can create pipelines, who can manage them, and who can deploy the releases. This supports separation of roles for SOX compliance, which is especially important if you’re working in a configure, price, quote application like Salesforce CPQ.
Putting the Pieces Together to Get a Better Alternative to Change Sets in Salesforce
Salesforce change sets have long been the bane of admins. DevOps Center enables admins and other low code/no code developers to deploy changes just as easily as pro-code developers. It does this by offering a user-friendly point-and-click interface.
All you need to do is click the “Pull Changes” button in the UI. This allows you to select and manage the changed source files. That means you don’t have to manually keep track of changes or review long lists of components to locate the specific ones you want to migrate.
Because the “Pull Changes” feature shows you all your changes, you can determine if you want to advance each of them in the release pipeline.
For example, let’s say you made a change for a Work Item that resulted in an adjustment to a permission set. However, you were trying out various changes before deciding on the right implementation, and now you don’t need all the changed files. You can simply leave the files you don’t need unchecked when selecting the components you want to move.
When you commit your changes, DevOps Center moves the metadata source files into a branch in GitHub. Once you’ve committed your changes and want to advance them to the next step in the release process, just push the Work Item to “Ready for Review.”
At this point, DevOps Center creates another Pull Request in GitHub. This allows your team to review your work and if needed, comment on it.
Salesforce DevOps Center Release Dates
If you’ve been following the news about DevOps Center, you’ll have seen various different release dates. And that’s correct, because it has been in development since 2019.
The developer preview started in September 2020. It allowed users to start with work items, make changes in development environments, and identify and commit changes.
The DevOps Center pilot started in spring 2021. This provided declarative ALM and source control integration, and it added testing, reviewing, and merging changes to the list. It also allowed users to deploy to UAT and production.
The public beta starts in June 2022. Salesforce beta features include hybrid team flows, usability, and change set parity.
General availability (GA) of Salesforce DevOps Center is expected in Fall 2022. At this point, DevOps Center will be a fully functioning replacement for change sets. It will offer fully developed application lifecycle management (ALM) with source control and org-based development for hybrid teams.
Post-GA, a significant amount of enhancements are expected. Key tool integrations will include Jira and Agile Accelerator, additional VCS providers, and testing tools.
More developer use cases will be added, including Code Builder integration and packaged-based flows.
Automation will be enhanced with built-in CI/CD. There will also be a Slack integration, and approval processes will be added.
Learn More About the History of Salesforce DevOps Center!
DevOps Center Extension Packages
Salesforce partners can develop extension packages for DevOps Center, although this stage is in its infancy. As we move out of beta into GA, expect to see a rising number of extension packages as more partners adapt and expand their offerings to this new, free Salesforce DevOps tool.
Is DevOps Center Right for You?
Do you want to know if Salesforce DevOps Center is right for you? Click here to learn about its benefits so you can make an informed decision.