Development and operations are like ‘East and West, and the twain shall never meet’? Not if the concept of ‘Devops’ has its way in your company!

For the past couple of decades, companies have kept their development and operational groups apart as two different entities. Irrespective of management frameworks such as ITIL v3 or Agile development practices, all of them pushing for continuous improvement and synergies, still the water between these groups stays deep. Releasing a new version into production is often a hard and feared part of the process, if not the hardest and most feared part of all. As a result, changes to the production environment are handled with great care and all due considerations, inevitably resulting in fewer and bigger releases, making them hard to do them right the first time. Or alternatively, developers will try to bypass their operations guys, seeking salvation in the cloud, until they find out these systems need to be managed as well.

Probably you know the saying ‘if something is hard, do it more often so you will get better at it.’ Devops promotes the idea of stopping to look at each activity as an individual activity, but rather to improve the flow of the whole value stream. Having small but frequent deployments done by a group of multidisciplinary members provides a way to become better at this. It also downplays the rock star mentality: everybody has to share in caring about the result and be responsible for the end result.

Does that mean we all will have to able to do everything? Certainly not, but working together towards a common business goal is crucial. The goal is not generate a new software release or run a server, the real objective is to enable the business to do business. In a way, this is similar to the group ownership in the agile methodology. Here usability experts, developers, testers and managers alike take responsibility towards the customer. Devops extends this concept across the usual boundaries and is a natural extension of the growing interest in ‘continuous deployment and improvement’. In the operations group, there is often yet another separation between network-, backup- and server-people you have to bridge. Here as well, all these teams must start working towards a common goal: the business goal.

On the technology side, concepts as virtualization, cloud and more recently ‘Infrastructure as Code’ act as enablers in this concept. Their use in large scale deployments is a huge success, and these technologies, as well as the lessons learned, find their way into more traditional enterprises. Clearly, when providing a service or product, you can no longer neglect the operational side of the company.

A matter of confidence

Concentrating on the flow can help change ict from a cost center into a competitive advantage. As your flow increases due to more automation, human resources can be re-deployed for an improvement of the quality of your work. Your developers will get a better understanding of the impact of their work on the business, and administrators can share their knowledge on non-functional requirements such as security and stability. This will encourage the emergence of a common culture and shared interest between the two different groups.

While increasing your flow to production, all changes must be tested thoroughly. No change to production should be done adhoc, and a strict match with the auditing and control strategies must be enforced. By keeping the changes small, they become easier to understand and it is crucial that the process becomes one of confidence. Flickr has been doing this for several years now and a new developer gets to deploy code into production the first day at work. This is asking for problems, you may think, but they can to do so because they have a good change control and testing harness in place. That’s renders them sufficiently confident to do 10 deployments of change into production per day.

A good place to start the interaction is by addressing the boundaries of every separate group. Start with the management of the servers of the development environment, or the monitoring scripts with business logic. When you start talking to the people in the field, you will be amazed about the ideas they have to improve the flow, but were not allowed to talk about because they were in the wrong group.

The movement started last year in Ghent, at the first devopsdays conference. Since then, it has been received with great enthusiasm around the world. Many people are acknowledging this way of integration and successful ‘devops’ events have been held in Sydney, Silicon Valley and in the near future in Hamburg, Boston and Sao Paulo. Be sure to check out

www.devopsdays.org for more information.

Patrick Debois and Kris Buytaert

” If something is hard, do it more often so you will get better at it.”