Agility Throughout the LifeCycle: The Rise of DevOps

Agile practices such as continuous integration are now commonplace, but continuous deployment is much less so.

However, some companies are achieving multiple successful deployments of new functionality per day , e.g. John Allspaw’s presentation: " 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr ".

The key here is having the right mind set to seek out opportunities for automation and then to actually implement them – whether through acquiring tools, or by developing scripts or local tools.

What About ITIL?
Many organisations have reaped large benefits from implementing ITIL practices within their service and support teams. However, the development side of the organisation has often not been included in such initiatives. Thus there is a still often a “wall” over which new releases are thrown. Once things are in production, the operations team may very effective at supporting it – but there is still that hurdle to get over.

There is nothing in ITIL which says this is the way it must be. Indeed, ITIL V3 takes a more holistic view of the whole lifecycle starting with service design. The concept of an application service then allows organisations to wrap up application development as part of the overall process – adding some useful checks and balances and improving communications and co-ordination. The Service Transition book covers the transition into production - but while looking at how to control it does not mean that it has to be slow or a burden - just well managed!

By taking a DevOps mindset, we are not asking operations to give up control – we are working with them to improve the overall process, and typically achieve smoother and faster releases with much less friction. The underlying principles are still the same.

How to Implement DevOps
If you want to implement this, how do you go about it? Can you hire a “DevOp” and expect all your problems to go away?!

The key starting point has to be around communication – ensuring that your development and operations departments are working together closely on a daily basis.

Look at what is causing deployment problems and releases to fail. Ensure that deployment considerations are factored in very early in the development cycle. Look at automation possibilities. Make sure you have a well managed common set of tools including your source repository.

Consider the throughput rate you are achieving – the rate at which changes are actually being deployed – and how long on average that is. Measure “inventory” – work-in-progress that has not been deployed – and seek to reduce it.

If your software architecture makes frequent deployment difficult, then seek to change it as a high priority (treat this as a major “code smell”) or item of technical debt. This can be a major issue with legacy code and tools, and may take significant time to fix.

Vendors and Tools
There are a number of companies and also open source communities which provide tools and methods :

• Puppet Labs’ Puppet
• Opscode’s Chef – open source “recipes”

Commercial vendors include:

• XebiaLabs
• Nolio (also included as part of Serena’s offering)

One of the advantages of the open source offerings is the way it encourages thinking and sharing within the wider community. People can get actively involved and engaged which is a major benefit for all (not to say that the commercial tools are bad!).

It is also important to realise that a tool will not solve the problems, or necessarily make a huge difference by itself. It is the mindset and practices around the use of that tool that make the most difference.

Summary
This