The scope and complexity of most enterprise Salesforce projects has grown to a scale that they can no longer be managed efficiently without a mature deployment, testing and collaboration process. This demands a new kind of partnership and understanding between admins and developers. But there are potential bumps in the road.

All organisations and businesses rely ever more on digital systems. They must increasingly trust the teams that maintain them to deliver innovation without risking downtime. Salesforce has become a leading enabler of business innovation by providing business administrators with easy-to-use tools and a stable platform that do not demand an in-depth knowledge of code. This has led these “no-code admins” to be able to iterate new solutions quickly.

As these administrators look for ways to organise, control and manage these solutions, they have turned to DevOps practices have been increasingly being adopted by the teams that manage these complex Salesforce instances. Consequently, DevOps has become the nexus for the most sophisticated ideas and practices looking at SalesForce at scale.

DevOps describes a thoughtful, comprehensive set of practices and attitudes that make it possible for teams to migrate changes from software development into production. This reduces 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).

Initial assessments of DevOps have focused just on development itself. It’s important to understand 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.

Yet there remains one big hurdle to cross – DevOps practices generally depend on using version control and other processes that are unfamiliar to most admins. Somehow the gap must be bridged.

Overcoming code

There’s an enormous mystique surrounding programming. Popular culture perpetuates this – especially through the shadowy figure of hackers, common to many modern films.

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 running command line scripts gives ANYONE the confidence that code is not a strange and inaccessible world.

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.

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. A major benefit is that they can now track and compare their work in version control alongside developers.

The life-saving version control

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 is the part developers are already good at so it makes little sense to have business administrators duplicate this effort.

Furthermore, Salesforce does not provide a native means to track work in version control, and most admins are unfamiliar with using command-line tools.   It is perhaps better to propose that once an admin is part of the 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 continuous integration 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.

Why make the effort?

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.

‍