A wise man once said, “If you are going to dive headfirst into DevOps, better pack a parachute”, aside from the fact that this man was me, the point is still valid.

Introducing true DevOps practices into a company is never an easy task and it was a task I found myself taking on as I started a new role at a smaller scale organisation. I was told that the company as a whole had started progressing towards maturing into a DevOps culture, this involved the developers using tools normally associated with DevOps in order to solve development problems and calling it DevOps as opposed to the actual DevOps culture, practices and support being in place. The changes made were effective at enhancing the development lifecycle but were completely separate and siloed from the rest of the organisation meaning that infrastructure needed to catch up so that the DevOps practices were fully utilized throughout the company. The major issue with DevOps is that it really is all or nothing, as soon as you have segregated processes and only half utilized technologies it completely negates the power of DevOps.

For example, if you were to use a configuration management tool to automate the installation of a few base packages you know you will need to be on every server in an environment only to then manually install other packages, change the version of existing packages and remove others, this negates the point in using a CM tool in the first place. The servers you build using configuration management should always be in a known state which is stipulated in configuration management. For example, it was to build a server using configuration management and someone deleted the server, I would be able to rebuild the server using the existing configuration so that it was rebuilt back to the state it was before it was deleted. This means that even if you are only going to manage the packages installed on a server using configuration management you need to manage all the packages and ensure no manual changes are made to them in an ideal world.

These were exactly the type of issues the company was facing with the “half-in half-out” approach to DevOps. If an organisation decides to take a DevOps approach then a plan needs to be put in place. It was all about discovering what problems the organisation was facing and how/if they could be resolved by adopting this approach and then creating a road-map of how we will implement the new changes and shifting the perspective of all employees to ensure the whole organisation had agreed to migrate to a DevOps approach. This is where the opening quote comes in to play, you cannot expect to throw tools at organisational and cultural problems and expect to have a DevOps culture in place, this may sound obvious but seems to be a frequent issue faced when organisations try to implement DevOps.

Now I guess the big question is “Well what did you do to mitigate and overcome the issues you were facing?”. Starting with the fundamentals and ensuring we had the correct foundations was the first step. After we had identified the issues we were facing, both as an organisation and from a technological standpoint, we had to plan what needed to change and the requirements for what needed to be done. This involved getting members from different teams such as the development and infrastructure team into a meeting room and creating an action plan in order to create some vision statements for what needed to be done, of which we then further broke down these visions into epics which gave us the following:

• Logging & monitoring
• Configuration management
• CI/CD
• Continuous testing
• secrets & password management
• version control
• client management
• Security
• Backup and Recovery
• Training and Documentation
• Migrating current infrastructure

These epics were what we decided needed to be in place in order to say what the first version of our DevOps framework would entail, the next step was to work out an appropriate order and priority in which to begin working towards these framework v.1 end goals.

For instance, we decided that a good place to start was logging and monitoring, of which we decided to build using configuration management of which clearly creates an obvious overlap between epics which was inevitable with such high-level goals. The important part with this is that we set the standard going forward and ensure everything we built going forward was replicable, secure and manageable as well as our configuration management being version controlled, idempotent and end-to-end. Splitting this epic into tasks and sub-tasks allowed us to plan appropriate sprints to which we could plan the work and begin working on our first goal for the DevOps framework.

This was the start of this organizations DevOps journey.