There’s a lot of buzz about Salesforce DevOps Center, which is due to be released for public beta later this year – but what is it exactly? And how can you optimize your environment management strategy to achieve the best ROI?
Salesforce DevOps Center is ‘the future’ when it comes to moving changes between different environments. But which environments do you use? In this article, we’ll take a closer look at DevOps Center, and we’ll explain how to determine which environment to use for which function.
What Is DevOps Center?
DevOps Center is Salesforce’s new release management product that provides a way to bring admins and developers together. It’s a powerful new product that allows Salesforce teams to streamline release management, and it’s positioned as the future of change sets. The great news is that it offers a better experience for managing change through the release path.
Here’s what you need to know:
- DevOps Center aligns Salesforce change management with best practices for application lifecycle management by introducing Version Control via GitHub.
- It requires the use of Developer sandboxes and scratch orgs – and it recommends using many of them.
- It uses established deployment pipelines to move changes through multiple testing and staging environments.
- Changes are automatically detected and available for selection. You no longer have to remember what you need to add to a change set.
- Environment management strategy – not simply tracking changes – is now key to successful change management.
A New Approach to Release Management
Salesforce DevOps Center offers an easy-to-use solution to enhance your release processes. And it’s a fundamental move away from change sets, which are on the way out.
To truly maximize your ROI from the product, you need to adopt a new mindset and a new approach. You should take full advantage of all your lower-level orgs that enable source tracking. This comes with a number of considerations.
First, Developer sandboxes, Developer Pro sandboxes, and scratch orgs aren’t rich enough for most development when compared to Full and Partial Copy sandboxes. Developer and Developer Pro sandboxes don’t contain any data. Similarly, a scratch org doesn’t contain data or metadata by default – plus, few admins go into DX to create one.
So you need a way to seed these environments with test data and in-flight metadata.
In addition, because Salesforce will eventually retire change sets, you’ll have to use established deployment pipelines to move changes through multiple testing and staging environments.
Last, but certainly not least, with DevOps Center, changes are automatically detected and available for selection. This means you no longer have to remember what to add to a change set.
What Does DevOps Center Include?
DevOps Center offers a smarter, more accessible way to manage releases in Salesforce. It combines several development tools, including:
- Projects: Everything involved with rolling out new functionality to your users.
- Work Items: The description of changes you need to make.
- Pipelines: The locations where you’ll perform the work and the paths you’ll use to move it to production.
Additionally, DevOps Center leverages some existing tools.
Version Control System (VCS) allows you to track and manage changes to software code in a repository over time. During Open Beta – from June 2022 – it will support GitHub, and it will likely integrate with other providers before general availability around September 20, 2022.
Source Tracking is specific to Developer sandboxes and scratch orgs. It automatically creates a list of the metadata changes you make in an org. You can send this list to a VCS.
Scratch orgs are a significant value add of DevOps Center – they’re faster versions of Developer Pro sandboxes. Both declarative and programmatic users can create them in a matter of seconds or minutes. We’ll discuss how to do this later.
When it comes to testing, scratch orgs give you exceptional control and granularity. While you must enable the metadata settings you want, scratch orgs can be configured to have only the settings you’re interested in.
You can set up a scratch org specifically for a particular team, task, or project. You can test a feature branch or just one issue when and where it makes the most sense. This alerts you to problems earlier on in the development process.
A scratch org consumes less storage space than a Developer sandbox. In addition, you can restrict access to specific metadata you may not want certain contributors to be able to access.
When you maximize scratch orgs in this manner, you can leverage them in a development strategy that aligns with branching strategies recommended by VCS providers.
DevOps Drives Innovation and Reduces Risk
DevOps accelerates innovation while reducing risk by applying the following principles:
- Ship often
- Ship small
- Build in isolated environments
- Automate deployments
Traditionally, the Salesforce environment has not been conducive to these principles. But with the launch of this new product, DevOps in Salesforce is achievable.
Environment Management Is Critical to DevOps Center
With these considerations in mind, the first step in adopting DevOps Center is environment management.
Environment management involves using your available sandboxes to give each admin or developer their own org. It fuels all aspects of DevOps execution and potential automation.
You can design your environment management strategy in the following three steps:
1. Determine How to Create Rich Developer Environments
You need the ability to get Dev or scratch orgs that look like mini versions of production on demand. They should contain the right metadata, a standard set of test data, and any project-specific data you need.
2. Establish Your Pipeline to Production
Salesforce prescribes a basic pipeline in DevOps Center that provides a development environment and a release environment – or production.
Salesforce recommends adding – in order of importance – integration, staging, and UAT environments. Each stage in the pipeline consists of a name, environment, and branch. There’s also a bundling stage where you package multiple work items together so you can promote them as a unit of change.
3. Define the Right Org to Use at Each Stage of the Pipeline
Salesforce recommends a Developer Pro sandbox, Developer sandbox, or a scratch org for the development stage.
It recommends a Full Copy, Partial Copy, or Developer Pro sandbox for integration; a Full or Partial Copy sandbox for UAT; and a Full Copy sandbox for staging.
For each stage, start with the highest level org you have. If you don’t have a type, use the next level down. On the table below, that’s the next level to the left.
How to Create a Scratch Org
By default, scratch orgs must be created in Salesforce DX. If you know how to code, you can quickly create a scratch org in five short steps:
- Install the DX plugin
- Authorize Dev Hub
- Create an org definition file or a Scratch Org shape
- Set up your DX project
- Run the “create” command
Once the scratch org is created, you need to seed it with test data. Tools like Prodly’s AppOps Environment Management enable non-coders to create and seed a scratch org all at once – with just a click of a button.
Automation Enhances Environment Management
From a project management perspective, there are clear advantages to giving everyone on a project their own sandbox.
Nevertheless, creating lower-level orgs and provisioning them with data and metadata takes time. That’s why it’s practical to automate the process so you can quickly and easily create orgs that already contain all the necessary data and metadata.
Final Thoughts
By now, you should have an understanding of the foundation of DevOps Center: environment management. To learn more, watch our on-demand webinar The Future of Change Sets.
