This article was originally published in ITProPortal
Across the globe, organisations and businesses rely ever more on digital systems and have to increasingly trust the teams that maintain them to deliver innovation without risking downtime.
Salesforce has become a leading enabler of business innovation by providing no-code admins with easy-to-use tools and a stable platform. As business needs evolve, no-code admins can iterate quickly.
However, success has its price. The scope and complexity of most Salesforce-using organisations has grown to a scale that they can no longer be managed efficiently without a mature deployment, testing and collaboration process.
The global DevOps community has become the gathering place for the most sophisticated ideas and practices around evolving these systems at scale. It is hardly surprising therefore that DevOps practices are increasingly being adopted by the teams that manage Salesforce instances.
Yet there remains one big hurdle to cross – DevOps practices generally depend on using version control and other processes that are unfamiliar to most no-code admins.
Somehow the gap must be bridged if DevOps is to realise its huge potential.
Defining DevOps
DevOps describes a thoughtful, comprehensive set of practices and attitudes that make it possible for teams to migrate changes from software development into production with minimal friction and waste.
It’s a big topic, but one that encompasses all the people, processes, and tools used to manage the development lifecycle. And it is of course, dynamic: even in the name, DevOps implies a process (moving from development – Dev – to production).
It is all too easy to underestimate the power of this approach. In addition, teams often focus just on development itself. But it’s important to also focus on the way work is developed, tested, and deployed, and progressively improving the process. Gradually this unlocks the ability to propagate changes swiftly and reliably across many environments including production.
A common adage is that DevOps tools are far less important than the culture shift involved. What matters is that everyone whose work impacts a production environment can collaborate on common systems. There must be a shared sense of responsibility for enabling innovation and reducing risk and confusion.
Version control is a lifesaver
As soon as anyone begins working in a development environment, they understand why developers make such a fuss when those environments are out of sync with production.
Making changes in these environments (creating fields, using App Builder, etc.) is the part developers are already good at. This is the creative part of the role and where developers get a lot of job satisfaction.
But Salesforce does not provide a native means to track work in version control, and most admins are unfamiliar with using command-line tools such as Git.
But for those staff (such as admins) who have not spent much (or any) time writing code, it’s extremely empowering to tap into the process of development and to track and compare their work in version control alongside developers.
The hacker mystique
There’s an enormous mystique surrounding programming. Popular culture perpetuates this – especially through the shadowy figure of hackers, common to many modern films. And the truth is that developers 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.
The gap between coders and non-coders is just the gap between those who are literate in a language and those who are not.
Think of getting comfortable with code as developing basic code literacy or even learning a language such as French.
Code does have a few unique points though. Firstly, it functions as a universal language – somewhat akin to music.
And computers give feedback on whether the language has been written correctly or not. This instantaneous feedback allows people to learn quickly, even when working on their own.
Even experienced coders struggle 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.
It is far more about having the attributes of patience, confidence, and motivation to work through this learning process repeatedly. Even a little experience using Git and running command line scripts gives ANYONE the confidence that code is not a strange and inaccessible world.
Admins: what happens when they 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, though many choose not to.
Once over that hump and comfortable tracking config changes in version control, admins gain immediate value from being able to review the history of changes and to roll back if needed. And most importantly, they can participate alongside developers in using an automated delivery pipeline to test and deploy their work.
Once an admin becomes a participant in this delivery pipeline, they share responsibility for keeping it running and making it better. ‘Making it better’ principally means improving the automated tests. If a team sets up a CI engine and delivery pipeline, tracking the work in version control is the only manual process. Computers will do the rest of the work, running deployments and automated testing.
If an admin can help build or specify those tests, they are helping ensure that the changes that they have made will be protected over time. Such tests bring long-term benefit to the organisation.
Bringing admins and developers together in a common system that lets them experiment with less risk of impacting production users is a no-brainer. Making changes directly in production orgs implies that every change is an experiment that puts data, users, operations and reputation at risk.
Admins and developers working on a common delivery pipeline is also an investment in collaboration and governance that gives admins more reason to talk to the development teams and ensures they can build together with speed and deliver to production with confidence.