Best Practices and Workarounds
Managing your DevOps Center release pipelines can be challenging, especially if you’re new to DevOps methodologies. Let’s take a look at the additional stages Salesforce recommends on top of the basic DevOps Center release pipelines, as well as the value of scratch orgs in your pipeline.
In addition, we examine whether you can have more than one pipeline in DevOps Center—plus, whether you can use the same environment in multiple pipelines. We also discuss what to do when you want to add a new team member to a project, what to keep in mind regarding the DevOps Center Release Manager Permission Set, and how to set up a pipeline without using a Full Copy sandbox.
Stages Salesforce Recommends in DevOps Center Release Pipelines
Salesforce requires a basic pipeline in DevOps Center where you first connect your source control repository to your final release environment and then add at least one development environment.
However, DevOps Center is intended to help improve the quality of your work by enabling frequent testing. That’s why Salesforce recommends adding at least the following stages between your development environments and the release environment: integration, UAT, and staging.
The Value of Scratch Orgs in Your DevOps Center Release Pipelines
When using Devops methodologies, it’s best practice to provide every programmatic and declarative programmer with their own development environment to avoid conflicts and overwriting code.
This is where scratch orgs can play a significant role in DevOps Center.
A scratch org is a temporary environment that you can customize exactly the way you want, use for up to 30 days for a small build, and then walk away. Developers have been using them for quite some time. Admins, on the other hand, have typically found them a challenge to create.
Fortunately, there are now third-party solutions that make creating scratch orgs accessible to admins, too. For example, Prodly DevOps includes a user-friendly one-click scratch org creation feature that lets you spin up an environment with all the metadata and data you care about in just a few minutes.
Can I Have More Than One Pipeline in DevOps Center?
Yes, you can. In fact, you need one pipeline per project.
So what does this look like in practice?
You could, for example, have three pipelines:
- One for the day-to-day maintenance of your Salesforce instance
- One for hotfixes that are critical to the proper functioning of your Salesforce instance
- One for special projects that require a significant amount of development
Can I Use the Same Environment in More Than One Pipeline?
Yes, you can use the same environment in more than one pipeline.
For instance, one or more of your pipelines will likely have your production environment as the final release environment. But you can also use the same Partial Copy sandbox for staging in multiple release pipelines at the same time.
How Do I Add a New Team Member to a Project With a DevOps Center Release Pipeline?
If you want to add a new team member to your project, you simply add a new development environment—either a Developer sandbox or a scratch org. DevOps Center does let you add new development environments after the pipeline is active and you’re already doing work. It doesn’t let you add any other types of environments, though.
If you want the new team member to have access to the same metadata someone else is using in another org, it’s more challenging. Remember: You don’t want two developers working in the same environment. This is a problem because DevOps Center doesn’t include a tool that lets you backfill lower environments with work that’s in progress elsewhere.
Fortunately, Prodly DevOps offers a tool that allows you to do this quickly and easily. It’s a very admin-friendly, compliant solution that offers access control so you can regulate who has access to what.
For example, let’s say a team member is working on a large project, and the project manager decides they need more help. You could give the new person access to the same development environment—but that goes against DevOps best practices.
Now, if the work had already been released, you could just refresh a sandbox. But that’s not the case.
Instead, you can use Prodly DevOps for the lateral metadata move to bring the work in progress from the first development environment into the new one.
The DevOps Center Release Manager Permission Set
When it comes to pipeline release management, it’s important to assign the right permission sets to your team.
The Dedicated Release Manager
DevOps Center has the DevOps Center Release Manager permission set that you should only assign to someone you want to allow access to the final release environment. Why? Because there’s no way to restrict someone with this permission set from promoting to certain environments—including production.
In essence, with the current permission sets in DevOps Center, Salesforce is encouraging the use of one dedicated release manager to promote changes through the pipeline.
If you choose to structure your team this way, you can make the process much easier, more efficient, and more effective by using a work management tool—like Jira in Prodly DevOps—to coordinate the flow of work.
Simply set up the tool so it notifies the release manager when changes are ready for code review, as well as when they’re ready for promotion. It’s a workaround to make your organization more sophisticated and give you more control.
Preventing Team Members From Promoting to Production
So what do you do if you want team members to be able to deploy work to integration or UAT—but not production?
Here’s the solution:
Set up a development project with a pipeline whose final release environment is a sandbox instead of production. Set up a production project with a pipeline that starts with that sandbox and ends in production. Then give the DevOps Center Release Manager permission set for the second environment to someone who’s allowed to deploy to production.
How to Set Up a Release Pipeline Without a Full Copy Sandbox
Most Salesforce professionals are trained to always think our Devops Center release pipelines have to go through a Full Copy sandbox to allow for adequate testing—but that isn’t necessarily the case.
If you have meaningful lower-level environments and a smart strategy in place, you can create a fully functional release pipeline without a Full Copy sandbox.
Sandbox Seeding
You can perform adequate testing in any type of environment that has an up-to-date schema. In other words, it must have an up-to-date metadata model of what you’re doing, along with a valid amount of relevant test data.
For example, you can use sandbox seeding to populate a Developer environment with the right metadata and data to make it functionable and valuable. This is helpful for all sorts of builds, from hotfixes to page layouts.
Test Early, Test Often
It’s DevOps best practice to test early and test often. The more you get your environments—including the lower-level ones—to look like production, the sooner and more frequently you can test.
Put only the most relevant data in your lowest-level environments, a bit more in integration, and almost all of it in your Partial Copy sandbox. When you do this, you don’t need to do any testing in your Full Copy sandbox—so you can leave that out of the pipeline.
FAQs
How do I define the environments in my DevOps Center release pipeline?
Begin by determining what types of environments you’ll need for each stage of the release process. Salesforce recommends a scratch org, Developer sandbox, or Developer Pro sandbox for development. They advise using a Full Copy, Partial Copy, or Developer Pro sandbox for integration; a Full or Partial Copy for UAT; and a Full or Partial for staging. Learn more about defining the environments in your DevOps Center release pipeline.
How do I set up sandboxes for DevOps Center?
To set up your sandboxes for DevOps Center, it’s advisable to use automated sandbox management and sandbox seeding. Then you have to enable source tracking for sandboxes and create rich developer environments. Learn more about setting up your sandboxes for DevOps Center.
