Complete Guide to Salesforce DevOps Center – How to Get Started

Do you need straightforward release management which doesn’t need much time, advanced skills, or a credit card number?

Salesforce DevOps Center is easy, free, and made by Salesforce. You should be able to install, configure, and start using DevOps Center in less than a day. In this guide we will walk through how to get started.

Creating an Org

To start, do not use your company’s Salesforce org or client’s Salesforce org to try this demo. Always experiment in free disposable orgs. To be cautious, use your browser’s incognito mode, or a different browser altogether.

You do need a Salesforce Enterprise Edition (EE) or an Unlimited Edition (UE) because we need sandboxes. Some 30-day free trials provide EE or UE orgs. I used the Energy & Utilities Cloud 30-day free trial, which gave me an EE org, for this demo:

Note: It does take quite a long time for the welcome email to arrive.

Source Tracking

Next, we need to log into production and enable “source tracking”, so that any dev sandbox created henceforth also has source tracking enabled. This is needed by DevOps Center so that any changes made by developers are automatically tracked (instead of manually ticking deployment items like we used to do in Change Sets).

In Production, go to Setup → Platform Tools → Development → Dev Hub, and then scroll down a bit.

Click on the slider to enable source tracking in production, but no need to enable dev hub:

Sandboxes

Next, let’s create two sandboxes for a simple deployment pipeline.

In production, go to Setup → Platform Tools → Environments → Sandboxes, and press New Sandbox. Then create two new Developer sandboxes called Dev and UAT.

While the two sandboxes are being created by Salesforce in the background, let’s keep going.

Installation

Next, is the installation of the package called DevOps Center.

Note that Salesforce doesn’t provide the ability to install DevOps Center in sandboxes because a sandbox refresh will cause loss of all your DevOps Center data. To evaluate DevOps Center, you may install it in an unrelated Developer Edition org (Demo org) though.

In our example, we shall install it in production because that is ideal for governance. In Production, go to Setup → Platform Tools → Development → DevOps Center.

1. Click on the slider to enable DevOps Center. And then click the button to Install Package.
2. Install for Admins only.
3. After installation, we should be able to see DevOps Center under installed packages in Setup.

Connected App

Next is a step to create a connected app. Go to App Manager in Setup, and click the button on the top-right for a New Connected App:

Fill in the details as shown below:

• Connected App Name: DevOps Center
• API Name: DevOps_Center
• Contact Email: <real email address>
• Logo Image URL: https://tinyurl.com/doc-icon
• Description: Manage your development and release processes
• Web App Settings Start URL: /sf_devops/DevOpsCenter.app

Then save.

1. Next, click on Manage for the connected app.
2. Then click on Manage Permission Sets for the connected app.
3. Add the permission set called sf_devops_NamedCredentials to the connected app
4. Save.

Give Some Permission Sets to Yourself

The various permission sets related to DevOps Center are explained in detail by Salesfoce over here:

Since we are only setting up one release manager (ourselves), we can safely skip the reading material and shall assign all the permission sets to ourselves:

• DevOps Center
• DevOps Center Manager
• DevOps Center Release Manager
• sf_devops_InitializeEnvironments
• sf_devops_NamedCredentials

Head over to Setup → Administration → Users, then assign the five permission sets to yourself:

Creating a Project and Setting Up the Pipeline

Finally, now we can open the App Launcher and open DevOps Center.

1. Go ahead and click on New Project.
2. And connect to your GitHub account.
3. Authorise forcedotcom.
4. You will then need to click on the New Project button again to proceed.
5. The project will be created both in Salesforce DevOps Center and in GitHub automatically.
6. Next, press Click to Connect to connect the final release environment in the pipeline, (i.e. to the production environment).
7. And then click under All Environments to connect Dev and UAT.

Let’s also remove some of the comprehensive pipeline stages, Integration and Staging:

Next, connect to the previously created Dev and UAT sandbox, and also set a branch name for UAT, for example UAT-Branch-One. 

Note that the UAT stage is a bundling stage – items deployed till here cannot be redacted. Newly created sandboxes might take quite a long time before you can log in from the generic test.salesforce.com domain.

After configuring, you can go ahead and press the Activate button:

Creating a Work Item

For our simple example, let’s create a work item which will involve creating a single custom object.

Enter the details of the work item. Then, connect the work item to your dev org.

Demo of Making a Change

Log into the Dev sandbox and create a custom object, for my example I have used “SFB”:

Then go back to production. Thanks to source tracking, you will be able to see that the custom object, its page layout, and a profile are already ready for fetching. 

1. Click the button Pull Changes.
2. Tick the items and commit the changes.
3. Next, click on Create Review on the top-right.
4. The reviewer can view the change request, then click the slider Ready to Promote.

Promoting the Change to UAT

The release manager can collectively promote several work items from dev orgs to UAT, with different deployment options.

If you remember earlier, we had selected UAT as the bundling or merging stage. Items deployed till here cannot be redacted.

Once user acceptance testing is passed and the production deployment date is reached, the release manager can deploy the bundle from UAT to production.

Select a version name or version number for the production deployment, and then Promote.

Final Thoughts

• Do not use your company’s Salesforce org or client’s Salesforce org to try this demo. Always experiment in free disposable orgs. To be cautious, use your browser’s incognito mode or a different browser.
• DevOps Center needs GitHub, whereas using BitBucket will be available in the future. Other code repositories are not supported.
• Unlike change sets, DevOps Center can deploy destructive changes and delete metadata. Deleting metadata had been an annoying manual step for a very long time, until now.

References

Install and Configure DevOps Center | Salesforce

Salesforce DevOps Center: A Deeper Dive | Salesforce Ben

Salesforce DevOps Center: Step-by-Step Tutorial | Salesforce Ben

Free Salesforce Developer Edition Org 30-day trials