I work with companies who are often incredibly immature when it comes to technical strategy delivery. That’s not to say some of the individuals I encounter are immature technically speaking, but overall need help in key areas across technology.

Because of this, and due to a conversation I’ve had recently discussing this very thing, I wanted to discuss ‘DevOps’. In laymans terms because like methodologies in Project Management I talk about here, ‘DevOps’ is one of those terms often used incorrectly or often without truly knowing what it is.

In a nutshell, (and to me) DevOps specifically involves running tools across both the technology stack (at development & organisational ends) & the business IS and IT ends, which help support the delivery of continuous improved software, integration and delivery. So if you’re endeavouring to be ‘Agile’ in your organisation, you’ll want your IT, Systems, Architecture & Development teams using tools which help support this way of working. To me, that’s DevOps in a nutshell.

The reason I’m being specific here is because DevOps (like Agile) has become a broad group of concepts that have catalysed into a movement and have spread throughout the community to the point where it’s a discipline in its own right.

Wikipedia tells me DevOps is ‘a software engineering culture and practice that aims at unifying software development and software operation’ and yet you can search for DevOps roles which ask for experience in specific DevOps supported software platforms – it can be confusing and for businesses who are trying to get their heads around it, I wanted to be very simple. Especially when I’m trying to explain it. Is DevOp’s a thing? A practice? A cult?

• DevOps is the ‘agile’ bit for your tech teams just as ‘Agile’ was the methodology bit for your Project Management Office.
• DevOps (like Agile) is a cultural thing and requires a mindset shift into how software is developed, tested & shipped.
• A number of software tools exist to support a DevOps strategy which when used in the right way, can create a truly agile environment across the board.

The discussion around adopting ‘Agile’ has been done to death as a discussion (read some of my take here) but in this post I’m interested in the myriad of tools available, and also the ones either I use myself on occasion or are my ‘go to’ recommendations as starting points if nothing else.

I recommend the following because they have the most immediate ROI and impact to a business from my perspective. Also, these are the ones I’ve specifically used at commercial level myself.

Environment Building

One of the issues I see plight businesses is the inconsistency of development environments. Freelance staff, Dev’s who leave, Dev’s who get to pick up the code pieces subsequently for example, all have their own way of working which is great, but when it comes to managing the code and product, it can give businesses a headache.

Plus if you’ve ever got down & dirty with software, trying to set up a Dev or test environment, compiling dependencies, access, kernel configuration, not to mention the OS, updates, any virtualisation configuration considerations – it’s a nightmare. Implementing consistency is almost an impossible task.

Vagrant is great. My go to recommendation available & compatible across everything and there’s an entire library of pre-built ‘boxes’ which can be useful. My real-world scenario is an automated tester in my dept. used his own kit and own software stack to peform regression testing. It created a massive single man dependency and also ensured no one could assist with his work. Plus the IT infrastructure security policies with things such as root access requirement made it difficult to have company-centric hardware set up this way so he used his own kit – not ideal for the company.

By running Vagrant and then checking out the latest version of the codescripts with the VagrantFile included, any new automation tester could then run this and not only get the scripts, but get the environment with a single command. This time, IT could get involved setting up all the network security parameters and signing off the environment prior – this meant when new testers came on-board, an appropriate environment was ready for them at the flick of a command line script.

Once automation of the environments has been considered, the next thing I like to get businesses to consider is the automation & scaling of their infrastructure itself.

Chef is brilliant for this. When it comes to setting up servers, you can set up directly over SSH for example. But for me, I like it because it makes it easy to set up servers via automation. The inbuilt monitoring & reporting tools are also epic. There’s a great video here https://www.youtube.com/watch?v=LmRykHIExH8 which covers using Chef & Vagrant together, and I suggest you spend seven minutes watching it. Being able to spin up servers for any purpose on the fly is something I just take for granted now and I watch in disdain as IT depts. Are crippled at process heavy procurement, set up & provisioning workflow meaning something which can take minutes & hours, often takes days & weeks.

On the subject of monitoring, especially when you’ve built those virtualised servers & development environments, Nagios (although expensive) is an awesome industry standard IT monitoring tool. The logs alone from Nagios make it worthwhile. In-built network analysing and security threat assessment make it a key tool in any CIO’s arsenal. It gives that at-a-glance reporting for any area of your IT real-estate & something I’ve found very useful, giving business leaders a clear ‘plain English’ picture of how their IT is doing. The dashboards it creates look awesome on massive TV screens and I’d always want to see Nagios in an org serious about monitoring.

There’s heaps of tools available, and there’s a great list here https://stackify.com/top-devops-tools/ but I’ve listed the ones specifically I use or have experience in but mostly, want to ensure when I’m talking to people about DevOp’s I’m clear about what it is.

The benefits of a solid DevOps environment can be profound, and the way software is often developed now means you really should consider cultivating this type of environment & ensuring your teams have these types of tools at their disposal. I watch companies like Ticketmaster really doing great things with DevOps & an ex-colleague of mine Connon MacRae did a great talk at WinOps 2017 about the work his team are doing in this area, which you can watch here.

Ultimately though, let’s ensure we outline some key business benefits for DevOps.

• Faster Time to Market
• Improved Collaboration
• Stable & Consistent environments
• Earlier detection & subsequent resolution of bugs
• Time to focus thus improving the end product