News

Explanations of the differences between the various “new” patterns and practices in software development can be found all over the internet. The Agile Manifesto, Humble and Farley, Allspaw and Hammond and dozens of other seminal publications contain the ideas, and the free and open source movement has ensured that the ideas are distributed widely and quickly. Here’s a quick description of some of the mots du jour, describing how they relate to DevOps.

Agile

Agile is a mindset in which change is embraced and value is delivered as often as possible. It is often used to describe only the software development lifecycle, and for many people, it stops before delivery process kick in. DevOps can work without Agile and Agile frequently works without DevOps, but they do complement each other nicely. DevOps requires constant communication and feedback, which initiates changes, which Agile teams embrace.

Lean

Lean (in software delivery) can be thought of as Agile throughout the organisation, including governance, development, delivery, finance etc. It is the extension of Lean Manufacturing (as conceived by Toyota and enhanced by Deming) in knowledge industries. Lean and DevOps can each work in isolation but they are so well matched that it is difficult to imagine a Lean organization ignoring DevOps once it learns of it.

Continuous Integration

CI is the practice of building all software as often as it is changed. This includes automation of source control, compilation, testing and packaging but does not include delivery or deployment of the packaged software. In organisations that develop software, DevOps cannot exist without CI, but CI is often used without any attempt at DevOps.

Continuous Delivery

CD is the extension of Continuous Integration to include delivering software to all environments, including production. It does not necessarily require that the software is released to users, only that it is there and available for release (for more on the separation of delivery from release, read up on topics like dark launching and feature toggles). DevOps benefits greatly from CD but it can be employed successfully without it.

Automated Infrastructure / Infrastructure as Code

Automated infrastructure is the practice of configuring infrastructure (containers and virtual machines, installed applications, network links, etc.) in code, storing that code in source control, and deploying the infrastructure from that code. It uses a variety of modern applications including Puppet, Chef, Salt, Ansible and Docker to configure the infrastructure. It is very suitable for use with scalable cloud-hosted applications, since new machines can be created on demand using the committed and tested infrastructure code. Anecdotally, it seems to me that quite a lot of people think of Automated Infrastructure as the end goal of adopting DevOps; DevOps thought leaders like Patrick Debois and Jeff Sussna might point out that this doesn’t go nearly far enough. But as a technical target, it’s pretty close to the mark.

I talk with people with widely differing understandings of DevOps. Some believe that it’s just a trendy term that describes nothing new (and they’re not completely wrong); some think it’s only for large companies that are already delivering software 10+ times a day; and some think that letting developers tweak the production database counts as DevOps. Hopefully, you’ve now got a better idea of what DevOps is and how it might help you and your organisation deliver better software, faster. 

Guest Post by Paul Hicks, IntergrationQA