Devops is a set of technical and non-technical processes. I have talked about it previously here: What is Devops ?.
But how do we go about executing these processes ?
In engineering, a process is a series of interrelated tasks that, together, transform inputs into Automation system
A process can be encoded in a document, enforced by a human or automated by a tool. In this post, I claim that any process worth adopting must be done via a tool.
Encoded in a Document
A process written down in a document is a nice idea to hear but tough to follow through. One has a confluence or github wiki page, enlisting the steps required to perform a task, and the links to it are thrown to a client’s face everytime they ask for it.
But then comes the inevitable back and forth on the interpretation of the written word. In time, the document decays and its content become ineffective and sometimes downright dangerous.
Enforced by a Human
A process enforced by a human performs a little better than documents. A human is a dynamic entity and can responds to changes as necessary. But a human is a human. They get sick, go on a vacation or quit.
Tooling over Processes
A process is communicated A tool is programmed
If something isn’t automated as part of a tool, you’re going to have to keep communicating it over and over again
What is it ? What is Tooling ?
Bespoke cli’s, ui’s, libraries that are highly tailored to the processes of a company. They are built when there aren’t any cost effective market solution with equivalent features.
A few Devops processes
Hooking up Monitoring and Alerts
Spinning up Test Environments
Oncall schedules and capturing incidents
What to build ?
Measure the frequency of process related queries and the time spent to resolve them to find out which tools need to be built.
When to build ?
Instead of reinventing the wheel, we should first try and look for both free and paid tools which can perform the task. Affordability and integration with internal tools can be concerns here.
A tool can become redundant too. But fortunately since it’s code, we can measure the progress of decay. They key is to treat a tool like a product.
Measure visits to a tool’s features.
Measure drop offs in the user journey
Measure latencies and completion durations
Take surveys to identify usability pain points
Deprecate features/tools with embarassingly low usage
Is it worth the time ?
Although the above recommentations sounds like a lot of investment for something as pedestrian as processes, but the benefits are abundant.
Stops repititive communication and prevents decay
Makes stakeholders self sufficient
Builds up a product mindset
Instead of writing or governing processes, building them into tools makes the collaborative contracts between teams highly visible and clear. For some companies it can be the secret sauce to success.
As is tradition, the closest XKCD reference I could find.