Organizations are increasingly reliant on digital systems, and trust the teams that maintain them to deliver innovation without risking downtime. Salesforce provides an extremely stable platform that allows no-code admins to innovate swiftly to meet changing business needs.
The scope and complexity of most Salesforce orgs has grown to a scale that they can no longer be managed efficiently without a mature deployment, testing, and collaboration process. The DevOps community has become a gathering place for the most sophisticated ideas and practices around evolving IT systems at scale. Those practices are increasingly being adopted by the teams that manage Salesforce instances; but they rely on using version control and other processes that are unfamiliar to most no-code admins.
Defining DevOps
Many people depend on your Salesforce org to get their work done, so making configuration changes directly in production is unwise. Small teams making moderate numbers of changes, often use change sets or manually migrate changes from sandboxes to production. But the process is tedious and error-prone. DevOps is a term used to describe a thoughtful, comprehensive set of practices and attitudes that make it possible for teams to migrate changes from development into production with minimal friction and waste. It’s a big topic, but one that encompasses all of the people, processes, and tools used to manage the development lifecycle.
If your company has invested in a click-friendly release management tool like Copado, consider yourself lucky – you can become a DevOps superstar with clicks, not code! If your company is taking a more traditional approach of directly using version control and general-purpose CI tools, don’t worry. You have an opportunity to learn powerful and flexible tools that are commonly used by teams working on a huge range of technologies.
The Role DevOps Tools Play
DevOps implies a process (moving from Dev to production), so it’s important to appreciate the benefits of not making changes directly in production. Your work then is to get access to a development environment, make and capture your changes from that environment so that they can be sent through the deployment and testing process, and participate in progressively improving that process.
A common adage is that DevOps tools are far less important than the culture shift involved. What matters is that everyone whose work impacts your production org is able to collaborate on common systems and that there is a shared sense of responsibility for enabling innovation and reducing risk and confusion.
Don’t Resent Version Control
Getting access to a development environment might mean using a shared Dev sandbox, or running commands to clone a short-lived sandbox or scratch org. As soon as you begin working in a development environment you will understand why developers make such a fuss when those environments are out of sync with production.
Making your own changes (creating fields, using App Builder, etc.) is the part you’re already good at. This is the creative part of your job, and it’s natural if you initially resent all of the overhead involved in capturing your changes to version control. But if you’ve not spent much (or any) time writing code, it’s extremely empowering to begin tapping into the process of seeing your configuration represented as XML and to track and compare your work in version control alongside developers.
The Gap Between Developers and Non-Developers
There’s an enormous mystique surrounding programming. Popular culture perpetuates this, as do developers, who enjoy the air of mystery and exclusivity of doing work that seems so alien to other people. But writing code is just writing. Code editors are mostly just text editors. And the gap between coders and non-coders is just the gap between those who are literate in a particular language and those who are not. Think of getting comfortable with code as developing basic code literacy. Just as illiteracy rates are falling globally (see the figure below), so too code literacy will serve you well in the modern world.
!https://www.salesforceben.com/wp-content/uploads/2019/12/1-14.png
World illiteracy has halved between 1970 and 2015
Amazingly, code functions as a universal language. But it’s one where computers give you feedback about whether you’ve written it correctly or not. This makes it well-suited to introverts who are happy to learn without human interaction. But even experienced coders struggle and fail like tiny children when first learning a new programming language or technique. Their peers may think they have super-human skills but, in private, even the most brilliant developers use “Hello World” examples and painstakingly pore through code snippets to get started with new technologies.
In my view, what distinguishes programmers is only that they have the patience, confidence, and motivation to work through this learning process again, and again, and again. Even a little experience using Git and running command line scripts can give you the confidence that code is not a strange and inaccessible world.
Admins: It’s Time to Get Involved
The best Salesforce admins I know have taken delight and pride in getting a little experience with code and the command line. Such experience unlocks the possibility of diving deeper into coding, even if you choose not to.
If you get over that hump and get comfortable tracking your config changes in version control, you are more or less home free. If your team has set up a CI engine and delivery pipeline, tracking your work in version control is the only obscure and manual process you have to do. Computers will do the rest of the work, running deployments and automated testing.
Facing Deployment Errors
You’ll have to face deployment errors. But you would face those even if you worked with change sets. And you might have to face Git merge conflicts. Merge conflicts for most metadata types are not hard to resolve, especially using a code editor like VS Code. But merge conflicts for Profiles and some other metadata types can be very ugly. This will help you understand why Salesforce is increasingly promoting the use of Permission Sets instead.
Automated Testing and Code Coverage
Finally, once you’re participating in this delivery pipeline, you share responsibility for keeping it running and making it better. Making it better principally means improving the automated tests. The testing tools your team is using may vary from developer-focused to admin-friendly. UI testing tools like Provar, Selenium, and Tosca are designed to be more accessible than code-based tests. If you have the opportunity to help build or specify those tests, you are helping ensure that the changes you make will be protected over time.
The logic you embed in a Process or Flow may be every bit as complex as the logic in a piece of code. Salesforce has begun to enforce code coverage requirements even on Flows and Processes, which is an interesting decision that affirms Salesforce’s view that automated testing is essential. Encourage your developers to write their unit tests in a flexible way so that the expected inputs and outputs can be tuned easily. Behavior Driven Development (BDD) style tests are meant to have human-readable inputs and output. That makes it easy to create multiple variations of a test to examine business logic against different edge cases. If developers write tests in a modular way, you can easily copy and paste a single test and adjust the inputs and expected outputs to help validate the logic of your Processes, Flows, Workflows or Validation Rules. Dabbling in unit tests is one of the easiest and lowest-risk ways to start to code, since they have no impact on the org’s behavior.
Summary
The point of adopting this approach is to bring admins and developers together in a common system that lets them experiment with less risk of impacting production users. Even Salesforce experts will occasionally screw up. If you’re not familiar with working in a development org it means that every experiment you do puts your data, your users, and their affection for you at risk. Working on a common delivery pipeline is an investment in collaboration and governance that gives you more reason to talk to the development teams, and ensures you can build together with speed and deliver to production with confidence.
