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’m unable to talk about Code Builder yet, but we hope to be able to share news on how Provar can be used with Salesforce DevOps Integration very soon.
We were fortunate enough to be invited to join the early access program for the Salesforce DevOps Center and hope to continue our involvement through the pilot phase starting in February 2021. There was a lot of excitement over this feature in the virtual TrailheaDX event in May and at DreamTX in December. So we’ve had a play with the early version. I’m excited to share that we have integrated Provar into the DevOps Center lifecycle so that you can run your tests as part of your DevOps Center development and release process. More on this later.
You’ll find links to the session recordings at the end if you missed those. Remember that this is a Salesforce feature not yet in 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, when asked if DevOps Center would be accessible, the Salesforce team replied ‘both free and paid options would be available. We can only assume there will be soft limits you can raise as a paid feature, much like other Salesforce DX features.
DevOps Center is Salesforce’s application designed to enable administrators to participate effectively in a source-driven development approach to managing Salesforce changes. In my opinion, Salesforce DevOps Integration will ultimately supersede both change sets and the ANT migration tool and give some of the weaker release management tools a challenge.
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.
Provar tests can be executed to validate a deployment and provide valuable evidence for User Acceptance Testing, and as a history of quality, gates met. In addition, multiple test plans can be run 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 results of the test execution. With Salesforce DevOps and Provar, you can see the actual test results, including screenshots, against each DevOps Center work item, speeding up the review and decision-making for when changes are ready to be deployed to production.
For those who haven’t seen DevOps Center yet, I put together the following playbook to walk you through 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 Developer Preview, this had to be GitHub, but as mentioned above, more platforms are planned very soon. DevOps Center automatically creates a repository for your changes using your Git credentials, so no Git knowledge is needed.
A DevOps Center Project Can Contain Several Work Items
Think of these as concrete developments you want to carry out to deliver a change, but 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 an action, such as running a Provar test, deploying the changes to another org, or using static analysis tools for Salesforce DevOps Integration. Currently, a colleague would generally review the changes after any additional actions and perform a merge of 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. The results of the Provar tests can be visualized in GitHub using the Provar JUnit result file, and you can also email out a full PDF test report if you wish.
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. When these actions are completed (and they can be automated in GitHub), we promote all these changes to our production environment. Unlike change sets, we can encourage multiple changes at once. We’re not taking any hacks from the staging org; we’re only deploying what’s been automatically synchronized into our source control.
Above: Salesforce DevOps Center – Promoting all staged changes to production in one action.
The Final Deployment is Now Complete!
Again, we can use a GitHub action to run a Provar smoke test of this change in production if we want to verify the changes are working as expected.
Above: Salesforce DevOps Center – Merge and deployment to production successful.
Virtual TrailheaDX 2020: DevOps Center Developer Preview
https://www.salesforce.com/trailheadx/demos/ Reference: The Security and DevOps section.
DreamTX 2020: DevOps Center (Registration required) https://trailblazer.salesforce.com/sessions?eventId=a1Q4V00002DWxkY#/session/a2q4V000001LvOyQAK
DreamTX 2020: Manage Releases Fast with DevOps (Registration required)