DevOps - The relevance of context

May 5, 2020

DevOps is like swag. Everyone want to have it. A lot of them do it wrong. A lot over do it, while a lot don't give a damn about it. So how much swag is good? How much you should do? Should you even think of it, or it's just another hype in the market. Let's find out.

In my previous blog, I tried explaining what is DevOps. It was about basics, but a clear basics are very important to make strength in the advance skills. As I talked there about the misplaced focus, this blog is an attempt to find out the right point to focus on.

So the question was - How much DevOps you should do? My answer for all such questions in technology ends with same generic reply - Only how much is needed. Though the answer is right, yet it has it's own problem i.e. lack of clarity on what is needed. So, we will try to make that part clear here.

So let, me rephrase my reply - Only how much is needed for your team, for their work.

So what got changed? I just added the context - Your team, their work. DevOps has principally three components:

Automation - Now a days, I lot can be automated. Example: infra setup, code build, packaging, deployment, testing, defect logging, monitoring, and what not. Trust me you don't need to automate it all.
Collaboration - Most unacknowledged part of DevOps. The Dev team, QA team and the Ops teams should be in sync along with the management. We never give this part a focus.
Agility - A team might have varying needs at varying time, in terms of automation and collaboration. DevOps should be able to address those challenges or requirements, if applicable.

Where do we go wrong

We go wrong when we ignore the context - Your team, their work. We start from standard CI/CD. This allows us to do auto builds and deployments. Majority of us think that DevOps is completed the day CI/CD pipelines start working. This approach towards DevOps needs to be changed, obviously CI/CD pipelines would be one requirement, but that's not the all.

Let's recall the DevOps concerns:

To increase speed.
To improve quality.
To cut the overhead.

So let's start from there. Before thinking CI/CD completion as end of DevOps, look into your team and their work. Find out the opportunities where you can find the DevOps concerns to be applied. Keep your eyes, heart and mind open for anything. Be as close as possible to the problems of your team; today's problems and tomorrow's problems.

Do all the developers has enough access to centrally build and deploy their work in the required environment?
Does QA team depends on someone to get work deployed in QA, UAT, Security, Perf environment? Can't you give them the access and remove the unnecessary dependency?
Can everyone, even managers, be aware of what is deployed where?
Are the deployments verified/smoke tested? Are the required people informed about the results?
Are the rollbacks configurable for each environment?
How does your QA team tracking what should be promoted to higher environment? Can you help them their in that tracking?
Can you differentiate between MUST HAVE, NEED TO HAVE and GOOD TO HAVE requirements?

The idea is not look fancy but solve the real problem around the context i.e. your team, their problems. As long as we be contextual, even a small implementation of DevOps can be far more useful than fancy automation possibilities.

Remember : Context is the king !!