How to integrate Provar with Salesforce DevOps Center

There’s no doubt that 2020 has been unprecedented in so many ways. Yet, despite all of the disruption, one thing that has not changed is Salesforce’s constant innovation and development. Earlier this year, we learned about several innovations from Salesforce that are especially interesting for the DevOps and QA communities. The first one is Salesforce DevOps Integration with Provar.

Two things, in particular, caught our attention:

Salesforce DevOps Center: In-org integrated source tracking and deployment management.
Salesforce Code Builder: Cloud-based virtual development environments that enable users to build using remote workspaces in their browser.

I can’t discuss Code Builder yet, but we hope to share news soon on how Provar integrates with Salesforce DevOps.

We were lucky to join the Salesforce DevOps Center’s early access program. We hope to stay involved through the pilot phase starting in February 2021. This feature generated a lot of excitement at the virtual TrailheaDX event in May and at DreamTX in December. We’ve explored the early version. I’m excited to share that we’ve integrated Provar into the DevOps Center lifecycle. Now, you can run your tests as part of your DevOps Center development and release process. More details will come later.

You’ll find links to the session recordings at the end if you missed those. Remember that this is a Salesforce feature that is not yet in the pilot and may not ever become generally available. However, it is on the roadmap for general release in Winter ’22 and is subject to feedback from the pilot and beta programs.

On the plus side, the Salesforce team confirmed that the DevOps Center will have both free and paid options. We assume the paid version will have soft limits that can be raised, similar to other Salesforce DX features.

DevOps Center is designed to help administrators participate in source-driven development for managing Salesforce changes. In my opinion, Salesforce DevOps Integration will eventually replace both change sets and the ANT migration tool. It could also challenge some of the weaker release management tools.

Before we get too far, if you haven’t already looked at our article on Salesforce release management tools, we recommend taking a quick look to remind yourself of the different options available today and how DevOps Center compares.

What We Learned About Salesforce DevOps Center

Here at Provar, we were fortunate to be involved in the Salesforce DevOps Center developer preview. As part of this early access, we gained the ability to do the following within our trial org:

Create Work Items to track tasks for development, like you might using Agile Accelerator, Jira, or Trello
Connect developer sandboxes and scratch orgs to our environment
Automatically detect and pull changes from an environment
Push changes into a GitHub repository and manage the pull request process for peer review

During DreamTX, Salesforce announced and demonstrated additional features in the official pilot, slated to launch in February 2021.

Pipelines for defining development, staging, and production environments and managing the deployment of changes through the pipeline
The ability to push changes into another org for review purposes

Even better, while still a forward-looking statement, Salesforce announced they expect to make DevOps Center a beta release around the Summer ’21 release and potentially general availability by Winter ’22. We can expect additional features before either of those stages, such as support for different source code vendors.

As early adopters, we wanted to try integrating Provar with the DevOps Center. We did this using our GitHub actions integration, but we also have support for GitLab, Bitbucket, and Azure DevOps, among others. The solution is broadly the same, with slight implementation variations.

In its simplest form, Provar can be run within these products using their inbuilt hooks for detecting changes and their pipeline automation. This means you can do the following:

Use Continuous Integration (CI) to Run Provar Tests When a New Change is Committed or When a Pull Request is Made

We recommend you use a small subset of fast-running, API-first tests to perform smoke testing of key objects. This gives the reviewer more confidence, especially when the change is declarative rather than code, so it has no unit test coverage.

Use Continuous Deployment (CD) to run a Provar Test Suite After a Set of Changes is Deployed Into an Environment.

You can execute Provar tests to validate a deployment, providing valuable evidence for User Acceptance Testing and a history of quality gates met. Additionally, you can run multiple test plans in parallel using different agents to minimize execution time.

Because Provar has built-in support for Salesforce APIs, we can test Salesforce and write back to an org to update the test execution results.

With Salesforce DevOps and Provar, you can view the actual test results, including screenshots, for each DevOps Center work item. This speeds up the review and decision-making process when you’re ready to deploy changes to production.

For those who haven’t seen DevOps Center yet, I put together the following playbook to explain how this may work.

DevOps Center is Installed as a Package Into Your Chosen org.

This doesn’t need to be the same org to which you’re making changes. However, it would be best to have a source control repository. For the Developer Preview, you had to use GitHub, but more platforms are planned soon. DevOps Center creates a repository for your changes using your Git credentials automatically, so you don’t need any Git knowledge.

A DevOps Center Project Can Contain Several Work Items

Think of these as concrete developments you want to carry out to deliver a change. You could make their user stories part of your agile development process.

Above: Salesforce DevOps Center – Work item details page.

DevOps Center Comes with a Default Lifecycle Workflow

Once you start Salesforce DevOps integration, you associate the difference with the sandbox or scratch org you’re working on and make changes as you wish. DevOps Center will allow you to identify all changes made using the source-tracking feature.

Above: Salesforce DevOps Center – Synching and committing changes for the work item; it is automatically tracked.

When You’ve Finished All The Changes You Want To Make, You Can Commit Your Changes

DevOps Center automatically handles creating a branch in your source named the same as your work item (WI-000002 in this case). Like change sets, you can add these changes iteratively. When you’ve finished all your commits, you set the status to Complete, which triggers the pull request to be created in Git for your branch.

Above: Salesforce DevOps Center – Work item committed and changes committed to Git branch.

We Now Switch To Our Source Control, Which Is Github In This Case

Here, we can see the branch created, the activity, and the pull request.

As you can see, it’s possible to automate actions like running a Provar test, deploying changes to another org, or using static analysis tools for Salesforce DevOps Integration. Typically, a colleague reviews the changes after these actions and then merges the pull request in GitHub.

Please consider this as committing to the changes and making them part of your project.

Above: GitHub – Merge the pull request created by the DevOps Center into the project mainline.

Here, I’ve taken an example of running Provar tests as part of the process for another change. You can visualize the Provar test results in GitHub using the Provar JUnit result file. If you wish, you can also email a full PDF test report.

Above: Provar execution as a GitHub action triggered when a DevOps Center request is made.

Now, We’re Entering The New Functionality Due For Release In Future DevOps Center Releases. (If I Worked For Salesforce, You’d See A Forward-Looking Statement Here.)

We’ve configured our development environments (dev sandboxes), a staging environment (most likely a partial copy or full sandbox), and our target production org for final deployment. I can take any of these changes and promote them to the following environment (staging) in the release pipeline with a single click.

Above: Salesforce DevOps Center – Promote an individual work item to the staging environment for testing.

The deployment happens for you in the background using Salesforce DX and your Git repository as the source of changes to deploy. This would be an excellent time to run a Provar regression test to check for unintended consequences and verify the changes are working as expected and using Provar.

After completing these actions (which you can automate in GitHub), we promote all the changes to our production environment. Unlike change sets, we can deploy multiple changes at once. We don’t take any hacks from the staging org; we only deploy what’s been automatically synchronized into our source control.