Editor’s note: this is a guest post contributed by Patrick Debois. The ideas and techniques now collectively known under the label “devops” have been gaining a lot of traction lately, but what people may fail to appreciate – our disdain for history again – is why these ideas arose when they did. Patrick lifts the curtain on the origin story of the Devops movement.
While working as a Sysadmin at a large enterprise, I got involved with a developer team that was introducing Agile within its methods. I admired the productivity and the down-to-earth pragmatic approach; even more I was witnessing better results than the typical relationship between the development group and the sysadmin group. Intrigued I was…
Thanks to many of the Agile resources like XPDay Benelux and various publications on the Internet, I learned both about the technical practices like TDD or BDD, but also about the cultural and human aspects and how they all resulted in a shift in mentality. It became apparent that for some reason the “last mile” of deployment and operations was not getting included in many of the discussions. The group closest and probably historically in between were the continuous integration and Build Master. I learned more about the fast feedback cycle by attending CitCon and found several people that could relate to being in between development and operations.
After extensive research at this position I got to change jobs and was excited to experiment with Scrum in an operational only group. Some things worked as expected: the relationship got better and the deploys smaller and more robust. But the strict cycles of a Scrum sprint where not working well: the speed of Ops work was almost sprints of 1 day; you would come in in the morning and re-prioritize your backlog and try work through it. In case of major downtime , the sprints were almost hourly for fixing issues. I noticed that under these extreme situations, people would collaborate even more and would be very focused. I wanted to maintain this collaboration constantly. On hindsight, kanban was probably a better option and I started promoting the ideas to extend the Kanban for development for Kanban for ops.
Thanks to the Agile Alliance, I was able to present these findings at Agile 2008 in Toronto. You can find the IEEE paper ‘Agile Infrastructure and Operations: how infra-gile are you” on my site. I got a lot of good feedback on it, and was convinced that there was real potential there.
During the same conference, many BoF sessions were announced and one caught my attention: “Agile Infrastructure”. I found the traditional ways of managing servers to be blocking the speed of change that agile development required. I really wanted ‘Agile Infrastructure’. So I went to the session proposed by Andrew Shafer (@littleidea) but… he didn’t turn up. 🙂 Luckily later during the conference we caught up and I learned he was working at PuppetLabs and we discussed how infrastructure as code could make the difference. Like me he was intrigued and had a background in Agile. In several of his next presentations he started promoting devops avant la lettre, it felt great not to be alone anymore.
After the session I tried to expose more of these ideas in the ‘traditional’ agile/developer conferences, but did not get any good response. People found it interesting but it was not there world, so no traction. Then via twitter I learned about Velocity Conf (large scale web operations Conferences) about a talk given by John Allspaw (@allspaw) about how Ops and Dev could work together. This was the spark for me to start my own mini conference ‘devopsdays‘. I called it devopsdays because I wanted to express the collaboration aspect. Since then the word ‘devops’ has taken off.
Many of the ideas originating in Lean, Agile, Kanban are being re-explored in the devops world now with the additional perspective of operations. A great incubator was the book on Continuous Delivery by Jez Humble (@jezhumble). It already contained ‘peeks’ into future collaboration between the two groups. Devops tries to introduce a holistic view similar to Theory of Constraints. Many of the “fast feedback” and “do often” mantras apply there too.
The idea of “infrastructure as code” has been an incubator similar to TDD: thanks to its practical angle it brings devs and ops closer together in a similar technical lingo: we are know talking about TDD , BDD for puppet and chef and CI systems that build systems instead of software. Besides the technical part, the cultural aspects are of major importance, we all know how hard it is to introduce a change to the ‘agile’ mindset.
I sincerely thank the agile community for exposing so many great ideas. We are now building on the shoulders of giants and extending the collaboration between project managers, developers and testers to the “last mile” of production… AND back.
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.