DevOps: Share a Vision for Automation

In the world of DevOps, there's a tagline we hear time and again - DevOps is a journey. A fair say given you can't achieve the holy grail for DevOps in a day. Every organisation who has jumped onto the DevOps bandwagon has had their own path of going through the journey. Some start with ad hoc practices whilst some take an organised and structured approach. Honestly, there is no right or wrong about any path provided you can measure the miles you have covered and you know that you are progressing in the right direction.

Any journey comprises of milestones and DevOps is no different. A key principle for DevOps is Automate Everything or, for the purist, Automate Almost Everything. Given the immense value this principle brings to the DevOps journey, one could think of realising this principle as a milestone in itself. But how can a team ensure alignment to achieve this milestone? A vision statement could help.

This article attempts to define and elaborate one such vision statement which could help achieve the milestone of automating the build and deployment aspects for a delivery team en route to their DevOps nirvana. It goes...

At a click of a button, use version controlled idempotent scripts to build immutable binaries and deploy to any environment created on the fly

For the purpose of elaboration, let's dissect this statement into parts and understand the significance of the words at play.

At a click of a button ...

Let's park this part for now and revisit a little later when it would make more sense.

... use version controlled idempotent scripts ...

This practice cannot be stressed enough. All that we do in regards to automation needs to be in a version controlled repository. Specifically, this alludes to build and deployment scripts amongst others. Also, these scripts need to follow the law of idempotency to ensure they yield the same result irrespective of the number of identical executions they are put through. The benefits of following this tenet are invaluable, especially when it come to troubleshooting and rolling back a change that has gone awry.

... to build immutable binaries ...

The word build here refers to the process of compiling source code and creating binaries that can be used during deployment. This part underlines the practice of carrying out the build process on a central build server using version controlled build scripts. The immutable part signifies the tenet of building the binaries only once by decoupling the environment specific configuration from the binaries. The idea is to build environment agnostic binaries which reassure the belief that if the binaries have worked in one environment, they would continue to work in any environment.

... and deploy to any environment created on the fly

The binaries created as part of the build process need to be deployed to the various environments in question. This would be facilitated using deployment scripts, again version controlled. The any environment part signifies the use of the same set of deployment scripts, and hence the same process, carried out repeatedly many a times thereby assuring reliability when it matters the most. The created on the fly part showcases the maturity of spinning up an entire environment when required, again using version controlled environment provisioning scripts, that reinforce our belief that no environment has been manually configured. So, if disaster strikes, any environment (including production) can be easily recreated by executing scripts, warranting no human intervention whatsoever, in turn encouraging the mindset to think of servers as cattle rather than pets.

At a click of a button ...

With the aforementioned elaboration in mind, let's go back to the beginning of the statement. We have talked of build scripts, deployment scripts and environment provisioning scripts, all housed in a version controlled repository. The combination of these scripts is what makes our build and deployment processes (or pipelines), processes that should be executed at a click of a button. In other words, clicking say the commit button should trigger our build process, clicking the provision button should create the entire environment for our application and clicking the deploy button, you guessed it, should deploy our application to the provisioned environment. These processes can be combined as deemed appropriate but the key takeaway is - Anything and everything happens at a click of a button. This paves path for simplifying complicated processes that can now be triggered by anyone (with appropriate privileges) thereby addressing the constraint around intellectual capital.

Now, it might make one wonder why the part "at a click of a button", which was addressed last, doesn't appear at the end of the vision statement. Meaning, the same vision statement can be reworded as ...

Use version controlled idempotent scripts to build immutable binaries and deploy to any environment created on the fly at a click of a button

True! But, it helps to influence a team better if "at a click of a button" appears at the very start of the vision statement. How? If you come to think of it, the entire DevOps automation aspect rests on the practice of triggering things at a click of a button. If you want people to get in the right mindset when thinking automation, the first thought that should come to their mind is a button that they would click to make the automation happen. Also, it's just human to easily remember the start of something rather than the end; this subconscious human trait could go a long way in fostering the much required paradigm shift in the way a team thinks during their DevOps journey. Commencing the vision statement with an action that signifies everything happens at a click of a button adds the required emphasis and gets everyone thinking in the right direction. If there were one thing you would want your team to remember about the vision statement, it is the start!

DevOps could be a long journey based on how you embark on it. Breaking it down into milestones using focused vision statements, even having infographics around them, can help keep the team on track and have them aligned with the overarching principles and practices that underpin the journey. Based on a team's level of expertise, a vision could be realised in a few months or a few years, but the duration is secondary; having one is primary. Have a vision to share...it helps.