Take The Salesforce DevOps Assessment to determine where you are in your DevOps journey and how you can take the next step.
If there is one thing we’ve learned since launching Blue Canvas and talking to thousands of Salesforce teams, it’s that adopting DevOps for Salesforce is a journey. There is no magic switch you can flip.
Also, DevOps for Salesforce means different things to different people.
Given that we’ve worked with hundreds of Salesforce teams over the years, we thought it might be interesting to share what we’ve learned. Teams might want to understand where they are on their DevOps journey and what the next logical steps are on their path.
So we’ve created The Salesforce DevOps Assessment. You can take it here.
Over the years, we’ve recognized that Salesforce teams roughly fall into four major categories. There is variation within each, but there are also significant identifiable common characteristics. Leveling up from one tier to the next requires understanding and implementing similar concepts in a fairly logical sequence.
We created the DevOps Assessment more as a teaching tool than as a means of labeling teams. The goal for the tool is to help teams understand the DevOps journey for Salesforce and how to take the next step.
In the assessment we’ve identified five major categories that we evaluate teams on:
Certainly there are other taxonomies but these are the ones that made the most sense to us.
A solid sandbox strategy is the foundation for any DevOps implementation in Salesforce. Like it or not (and we took some heat on HackerNews for this) Salesforce is a development platform. The beauty of Salesforce is that it provides sandbox environments that handle some of the repetitive aspects of application development such as security, authentication, scaling, database management and scheme migrations, executing code, cloud hosting, etc.
You’d be surprised at how many teams still make changes in production or have just a single sandbox that they use before production.
Further up the scale, you have teams that are using multiple stages such as Dev, Integration, UAT, Staging, Training before changes reach their production environment.
And at the far end of the scale you have teams that have highly complex and sophisticated sandbox strategies with refresh schedules, scratch orgs as feature branches and other more complicated flows.
Though it’s been a growing movement over the last 5 years, many teams still don’t have any real version control in place for their Salesforce environments. If they do, it might be highly limited such as having an Ant script run every night to “backup” metadata. Often, teams will have Apex in a Git repository but they don’t have a good way to help admins commit configuration metadata like Workflows, Process Builders, or Custom Object xml into source control.
Source control is important because it provides the ability to rollback bad changes, restore from backups, avoid code clobbering, and audit changes to the system.
With the advent of Salesforce DX, source driven development has become a major topic in Salesforce dev circles. Having a source driven development flow is the foundational layer for any DevOps strategy. It’s almost like the air we breath or the water a fish swims in. A DevOps team working in say Java or .Net could probably not even envision a development platform without source control and might even take it for granted that it belongs in the DevOps flow.
It’s not that teams have bad intentions - Salesforce makes getting metadata under source control rather difficult. Fortunately, there are new ways to get your declarative metadata and Apex into version control.
Historically, Salesforce provides twop ways of deploying changes between environments: change sets and the Force.com migration tool (aka Ant scripts). Neither is wildly beloved.
After getting called out twice as the “most dreaded” development platform. Salesforce answered with a new way of deploying based on modern technologies: Salesforce DX. It was meant to provide Salesforce teams with another set of tools that they could use to build DevOps pipelines. It’s a fairly advanced tool and is used by mostly greenfield projects and the true elite of Salesforce dev teams.
As Salesforce teams start to look and behave more like software development teams on other platforms, more teams are experimenting with Continuous Integration servers like Jenkins, Travis and Bitbucket Pipelines. One powerful feature is that these tools are highly customizable. You can use them to trigger pre- and post-deployment actions such as kicking off a Salesforce validation and running Apex unit tests before a code review. More advanced teams can run additional automated functional tests and static code analysis.
Whether you are making quality gates and automated functional tests a part of your Salesforce deployment pipeline says a lot about where you are in your DevOps journey. Though not every team makes this part of every release, more and more teams are adopting these practices and the technology is making it easier to do so.
Static Code Analysis.
Static code analysis can give you a health report for your Salesforce code. There are open source tools like SonarApex which can give your Apex code a health score based on bugs, security vulnerabilities and code smells.
Static code analysis is a great first step towards code reviews because it gives you something to discuss, and it can be done in an automated way, removing the human element that prevents many teams from taking action.
Static code analysis also helps promote and maintain quality within a long running Salesforce application. Most Salesforce applications are either already legacy or will become legacy and will be expected to run for years. With the prevalence of consultants and competitive market for Salesforce dev talent, the same developers working on your code in 12 to 24 months may not be the same developers who wrote the initial code. Static code analysis can ensure that you don’t end up creating piles of technical debt and can continue to grow your Salesforce implementation for years to come.
Advanced teams even set up quality gates to prevent deployments that don’t meet certain standards.
Automated Functional Testing.
Automated functional tests are a big part of most Agile deployment processes. It speeds up your QA cycle and reduced the chance of manual errors. Selenium has emerged as the leading tool for doing automation for web applications and Salesforce teams are starting to use it more and more to test Lightning Components and other UI elements.
With modern CI/CD servers it’s become easier to configure automated functional tests to run on a schedule or at particular points in your release pipeline.
Are you using spreadsheets to keep track of your Salesforce changes? Word docs? Many teams are. Teams are starting to invest in ALM (Application Lifecycle Management) tools like JIRA to keep track of work. Having a proper ALM in place allows you to keep track of who is doing what and when it will be done.
How often do you deploy? Continuous integration opens the possibility of Continuous Delivery which would allow you to get new features out to your users as soon as they are ready. This is especially useful for bug fixes. Having a pipeline that can get a change out into production immediately without disrupting other work is a big win for most Salesforce teams.
Are you doing code reviews? Much like static code analysis, code reviews are especially important in the Salesforce ecosystem because you often have:
Sure, code reviews can help spot errors and bugs, but more importantly they allow you to maintain a level of consistency and quality across your application. They also allow for knowledge to be transferred across the team.
You’ve taken the assessment. Here’s where you stand and where you can go next.
About you:
You have a well thought through sandbox strategy. Every developer and admin has their own sandbox and they are committing regularly to integration, staging and UAT environments upstream. You’re probably not using scratch orgs but you looked at them and decided it was better to wait until Lightning Developer Pro Sandboxes go GA.
Source control is a breeze for you. All of your devs and admins are committing regularly into source control. Nothing in your orgs isn’t properly tracked in your source control system. Deployments are driven from source control, and if there was ever an issue in production you could rollback quickly and easily without breaking a sweat.
Your deployments are fully automated. Pull requests kick off builds with a CI server and run Salesforce validations and Apex unit tests. Depending on where you’re at you might even be running automated functional tests as a post deploy steps. You haven’t used a change set in months. And each developer is able to deploy to upstream environments (within in reason) without having to bother the “Ant expert”.
Deployments are gated with permissions about who can deploy where.
You’re doing at least one or two of the following three things:
Your deployment schedule depends on your business needs, but if you wanted to you could easily deploy a hotfix within minutes without disrupting other work.
Where you can improve:
You are in the “sharpen the saw” stage of the DevOps journey. Your process works pretty well and now you just want to refine and add further improvements. Very few teams are doing proper quality gates so maybe you want to invest there. Maybe you want to increase your test coverage from Salesforce’s 75% to something higher like 80 or 90%.
About you:
You have at least 3 development stages: development, staging and production. Maybe staging even includes an integration step. Every developer may or may not have their own sandbox - things are a little more ad hoc. Admins kind of live on their own island.
You have source control with Bitbucket or GitHub but it isn’t quite perfect. Not everyone is using it as a daily part of their workflow. Maybe you have an automated script that “backs up” everything on a nightly basis. But it’s pretty broad.
You still use change sets sometimes but you also have some automation with Ant. Maybe there is an “Ant expert” on the staff and they are starting to become the bottleneck and have become the only person who can deploy. Maybe you have a Generation 1.0 commercial release management tool which feels better than nothing and provides some value but you haven’t added any new improvements in months.
You’ve read about functional tests and quality gates. You know what they are, but you haven’t been able to implement them across the team yet. Code reviews happen on an ad hoc basis, or among one or two of the more technical members of the team.
Where you can improve:
Fortunately for you, the tooling options have improved vastly in the last three years so there are new things you can do. A few ideas for low hanging fruit:
About you:
You’re here because you know that DevOps and CI/CD are aspirations you have for your organization, but you haven’t really gotten started.
You primarily use change sets to do deployments. You might have figured out a way to get some of your Salesforce metadata backed up in a Git repository but not everyone knows how that works. Or maybe you don’t have any source control yet but you know that you need to.
You have read about quality gates and automated testing or maybe you’re just encountering that via this assessment.
You see the value of DevOps and you just need a way to implement it.
Where you can improve:
Good news! You have the most low hanging fruit available to you so there is a lot you can do. The first big barrier to using DevOps for Salesforce is knowing that you need it. If you’re in this group, you’ve crossed that chasm and can start making rapid gains.
About you: To be honest, we’re amazed that you are here! This is the beginning of your journey. If you’re in this bucket and you’re taking this quiz, you have the hunger and interest.
Your organization may not be large enough to have invested in this yet or maybe you’re the only admin. You can still benefit from DevOps and source control if not a full CI/CD flow.
Where you can improve:
.png)