In our last post we depicted a DevOps-driven agile methodology, which looks something like this:

vs. a standard agile methodology, which looks something like this:

We then went on to describe 4 critical ingredients that are required to succeed in optimally implementing a DevOps-driven agile methodology, including

– The DevOps tool chain
– The DevOps operating model
– Platform
– Culture

In this post we will cover the first ingredient – the DevOps tool chain – in more detail.

To do DevOps right, it is critical to automate, re-architect (re-arch), and/or implement  as many of the activities involved in the development, build and test, and deploy workstreams as possible. The table below outlines the key activities within each workstream, whether these activities are in-play for automation, re-arch, or implementation, as well as the typical benefits derived from automation, re-arch, or implementation of the activities.

It is worth noting that in agile development, each “sprint’ cycle is generally anywhere from 1-3 weeks long, with around 2 weeks being the typical sweet spot. Without the automation, re-arch, or implementation of all of the activities listed above, it would be close to impossible to deliver a DevOps-driven agile methodology. What would remain with limited automation would look at best similar to the more traditional agile development process, and at worse a legacy waterfall process. This does not however mean that automating, re-architecting, or implementing any of the key activities outlined above, in and off itself does not drive any benefits. For example automating functional testing reduces the amount of time required to regression test as well as reduces human error. That said, in order to increase the the velocity with which code is deployed to production, i.e. to implement a DevOps-driven agile methodology, all or most of the activities outlined in the table above have to be automated, re-architected, or implemented.

So what does the DevOps toolchain look like, in terms of the vendors that play a role in it? The image below is an attempt at visualizing this:

As we close it is also worth noting that when companies, vendors, and recruiters are typically referring to DevOps, they are referring to the “DevOps toolchain” depicted in the image above, much more so than any other aspect of DevOps, i.e. the philosophy and methodology, or its operating model, platform, and cultural dependencies. It is worth remembering (and reminding) though that adopting DevOps, minus the operating model and culture in which DevOps can thrive, will significantly minimize the value of DevOps. Moreover adopting DevOps without the appropriate platforms (read cloud infrastructure) is typically a non-starter. More on these in future posts.