There’s no doubt that 2020 has been unprecedented in so many ways. Despite all of the disruption, one thing that has not changed is the constant innovation and development from Salesforce. Earlier this year, we learned about several new innovations from Salesforce that are especially interesting for the DevOps and QA communities.
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 which 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 it very soon.
We were fortunate enough to be invited to join the early access program for Salesforce DevOps Center and hope to continue our involvement through the pilot phase starting in February 2021. Both in the virtual TrailheaDX event in May and again at DreamTX in December, there was a lot of excitement over this feature. We’ve had a play with the early version, and 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.
If you missed those, you’ll find links to the session recordings at the end. Remember that this is a Salesforce feature not yet in pilot and may not ever become generally available. It is on the roadmap for general release in Winter ’22 and subject to feedback from the pilot and beta programs. On the plus side, when asked if DevOps Center would be free, the Salesforce team replied ‘both free and paid options will 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 that is designed to enable administrators to participate effectively in a source-driven development approach to managing Salesforce changes. It is ultimately, in my opinion, going to 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 taken a look at our article on Salesforce release management tools, then 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 developer preview of the Salesforce DevOps Center. 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 coming in the official pilot which is slated to launch 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 very much 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 and we can expect additional features before either of those stages such as support for additional source code vendors.
As an early adopter, we wanted to try out integrating Provar with 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 that you use a small subset of fast-running, API-first tests to undertake basic smoke testing of key objects. This provides the reviewer some additional level of confidence, especially when the change is declarative rather than code so 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. Multiple test plans can be run in parallel using different agents to minimise execution time.
Because Provar has inbuilt support for Salesforce APIs, we’re able to not just test Salesforce but also 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. You also need 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 a number of work items
Think of these as concrete developments you want to carry out to deliver a change, but you could make them user stories as 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 work on implementing a change, you associate the change with the sandbox or scratch org you’re working on and make changes as you wish. DevOps Center will then allow you to identify all changes made using the source-tracking feature.
Above: Salesforce DevOps Center – Synching and committing changes for the work item, which are 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 our branch that was created, the activity and pull request. As you can see it’s possible to automate an action at this point, such as running a Provar test, deploying the changes to another org or using static analysis tools. Currently a colleague would normally review the changes after any additional actions and perform a merge of the pull request in GitHub. Think of this as committing the changes and making them part of your project.
Above: GitHub – Merge the pull request created by 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 result of the Provar tests can be visualised 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 be seeing a Forward Looking Statement here.)
We’ve configured our development environments (which are dev sandboxes), a staging environment (which is 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 next 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 a good time to run a Provar regression test to check for unintended consequences as well as verifying the changes are working as expected also using Provar. When these actions are completed (and they can be automated in GitHub actions) then we promote all these changes to our production environment. Unlike change sets, we can promote multiple changes at once, and we’re not taking any hacks from the staging org, we’re only ever 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 wanted 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)