DevOps without DevOps tools
Once upon a time, a group of people disconnected from each other struck a common awareness of making things better. They observed their software development processes carefully and found gaps.
They knew nothing of Jenkins, CircleCI, SonarCube etc, but in their endeavours of identifying the gaps and possible solutions they started optimizing the processes and ultimately started using some tools to automate executing those processes for them.
This article is an excercize to simulate that mindset. I would really like comments and notes on this, but even if you process it in your head and don’t want to leave a note/comment, that’s fine. Because as long as this article offers you a little switch in the cognition, it served it’s purpose.
Playing with conflicts
Let’s consider that these common DevOps tools that we know of are not known to the community yet or they simply don’t exist. With that in mind, let’s list a few very common conflicts/gaps that DevOps helps resolve, and try solve/minimize them as far as possible (I am keeping things like scaling or hardware dependencies out consciously, don’t want to see unnecessary diversion of discussion):
Developer needs access to the production servers
Why? Do you need access to the server or logs? DevOps definitely does not equal developers managing production.
I would rather write bash scripts to alert/log if there are any changes in the dependency executables and give ftp access to download different logs, where I don’t want to give server access for some reason (compliances, policies etc). As far as deploying the code is concerned, Git pull/fetch worked then and it works now, manual or script is still a decision I can make.
What will be your way out?
Whose fault is it?
This calls for a postmortem report. However, DevOps is not about blaming, but to enforce learning from mistakes and being smart about how to best avoid them.
If I already have my scripts as above, making sure that the servers /environments are identicle. We can be smart about failures and can leverage things like feature toggles (and bi-weekly/monthly cleanups for the technical debt it causes). Also, good retrospectives are always there to nurture the team.
Can you think of something else? please feel free to add.
Continuous Delivery without Continuous Integration
DevOps methodology understands development to delivery (SDLC) equation. They focus on the processes that add value, organize themselves around development and delivery actions and do the best to minimize the risk.
Before the advent of DevOps, SysOps/IT used to work by treating all the stages in the SDLC with equal importance. And when all the steps are of equal importance, you tend to invest in sophisticated scheduling and communication systems to oil your processes.
Therefore, it is fair to say that DevOps without any of the tools that we know today is simply “communication” between two independent departments/tools/engineering units.
There are many conflicts that can be discussed and I don’t want the content any longer than what is needed to trigger that specific cognitive shift. However, It’d be great to know what more things you can think of.
Things going wrong
Somehow the word DevOps is just becoming a marketing title for what were always good practices in any industry (you want to make things better right?). You’ll hear the phrase — ‘we were doing DevOps before we even knew it was called DevOps’ quite often at conferences. And they did not need tools, tools were instead decided/made after careful examination of the problem statement.
The world seems to have lost this mindset, the border-line between a DevOps and SysOps/System Administrator is no longer visible and the community is starting to lose its essence.
At its core, DevOps puts people before products and is about looking at the larger picture.
DevOps means caring about your job enough to not pass the buck, wanting to learn all the parts as a whole, and not just your little world.
— John Vincent
More on this from my talk at scrum.org meetup
Join our community Slack and read our weekly Faun topics ⬇
