Continuous Delivery (CD) and DevOps have emerged in the last couple of years as practices geared to improve delivery speed while maintaining software quality and stability. The ultimate goal being to provide agility to business changes.
However, a lot of people still wonder what this actually means on the ground. How do you know if you have a DevOps culture? How do you go about changing established ways of working, processes and responsibilities? Which CD patterns are more likely to solve the problems your organization is facing?
The book “Continuous Delivery and DevOps: A Quickstart Guide”, by Paul Swartout, addresses these and other questions (such as how to identify pain points across the entire product development pipeline, not just in particular activities) in a concise and straightforward way, without much technical jargon. It is a book written by a manager who understood how CD and DevOps can help organizations deliver faster.
A lot of the practices extensively described in the reference book for Continuous Delivery are distilled and presented here in an introductory style. Other clever practices are added such as the deployment transaction (a manual queue system for serializing but most importantly dealing with component dependencies in a collaborative fashion). It should be clear however that this book will equip the reader with a set of starting points and watch-out-tips more than a roadmap for adopting CD or DevOps. This is stated by the author himself throughout the book.
If conciseness is one of the key strengths of the book then occasional over generalization might be its weak point. The need to present the practices in simple terms sometimes overshadows their potential complexity in particular contexts. Despite the traction gained by CD and DevOps in agile web and mobile environments, a vast number of enterprises are still dealing with legacy technologies which can present technical hurdles and debt making the journey towards CD and DevOps significantly more complex on the technical side.
Nevertheless, it is comforting to know that ACME, the fictitious company illustrated in the book, is to some extent based on Paul’s experience implementing CD and DevOps at Nokia Entertainment. It is living proof that large organizations with entrenched formal processes can change and adapt behaviors to their needs instead of their size.
To sum up, this book is a good starting point for newbies in the CD and DevOps practices as well as for those facing the challenge of changing large and/or formal organizations with complex development and release processes. For those already halfway through the journey this book can still provide some gems of advice (especially on culture and people’s behaviors) from practitioners in the field.
InfoQ talked with Paul about the motivation and goals of this book.
Is it fair to say that ACME systems is a pseudonym for Nokia Entertainment?
Paul: ACME systems is based upon elements of Nokia Entertainment mixed in with my experience in and observations of how other software based businesses have evolved. This is by no means a unique story and I've tried to reflect the natural life-cycle of many start-ups who grow, get noticed by larger businesses, get acquired and go through growing pains. Some come out the other side stronger, some don't. Luckily Nokia entertainment did.
What was the motivation to write this book?
Paul: The main motivation was to share my insights with others and hopefully boost the mainstream awareness of continuous delivery and DevOps. CD and DevOps seem to have a reputation of being geeky and the realm of software engineers and systems operators. I'm your typical management type but I get it. I may sound a bit altruistic but I believe (hope) that if more people get an insight into how to deliver quality software to customers quickly, effectively and frequently they will also get "it" and realise the business benefit "it" can bring. In addition they will see that spending less time and effort trying to ship / support software will allow more time and resource to be spent creating products that their customers want.
Who do you think will benefit more from reading it?
Paul: I wanted the target audience to be quite broad and as such I have tried to bring some value to as many people as possible - be they SVPs of tech business, IT managers, software engineers or individual IT professionals. In essence anyone who is involved in or around the delivery of software. Combining continuous delivery and DevOps into one book should also help those with experience in either, appreciate the other. My book is by no means the be all and end all but should help the reader familiarise themselves with the concepts of CD and DevOps.
How does the size and formality of an enterprise affect the successful adoption of CD and/or DevOps?
Paul: Despite what some of us are told as young men, size does matter. It is inevitable that the bigger the organisation the more entrenched the formality and bureaucracy. Implementing any business change in such an environment is difficult. Implementing changes to how people work, think and operate day to day is even harder. Not impossible just harder. In large organisations, my view is that you start small and build up - if you try and change everything overnight from top to bottom you will fail. You need the buy-in from those near the top but they need to be convinced, so if there are some success stories to share from the shop floor - a body of proof if you will, the chances are adoption can grow and flourish. The more success, the more buy-in, the wider the adoption.
In your experience what is the hardest and what is more time consuming: implement sufficient tooling and technical processes or change culture and behaviors?
Paul: I think it would be true to say that changing culture, behaviours and winning hearts and minds is much more difficult to implement than tooling. For a start tooling is dumb and will do what you design and ask it to do. People are not. Processes can be easily created and / or tweaked to better fit your business - people's default behaviours can't. Tools and processes are simple to understand, people are complex. You therefore need to apply effort and time to helping people understand what's in it for them and why changing what they are doing is for the best. Don't get me wrong, putting together the correct tooling to fit your needs is not an easy / cheap task - just not as consuming as people.
You point out in your book the need to balance automation of processes (in particular deployment) with enough room for discussion and face-to-face collaboration to solve difficult problems. Do you have any tips on how to assess when automation is needed or not?
Paul: There's no simple rule to apply here apart from using common sense. For example, if you have a manual task which is normally completed by one person and is repeatable (for example a software build and set of test scripts) then automate it. If you have a process which needs interaction between more than one person then consider if automating the process will bring people together or drive them apart. There is a tendency to try and automate everything in sight but sometimes that can cause more problems than it solves. The daily scrum is a good example of this - everyone gets together and discusses what they have done, what they are doing and what help they need. You could automate this in the form of an email / forum / discussion board but where's the value? Forming relationships and trust (especially across different organisational boundaries) is as valuable as reducing manual overheads.
Considering this is a quickstart guide, what other resources would you advise for someone who has read your book and wants to know more?
Paul: As you point out, this small book is simply a quickstart guide for those who want an introduction into continuous delivery and DevOps. There is a large and growing number of other rich resources available, some of which I have included in the book, some on my website. My default recommendations would be the blog of Jez Humble and Dave Farley the authors of the continuous delivery book / bible, DevOps Days which is the place to find out about DevOps events, the weekly newsletter about all things DevOps and CD sent out each week without fail by Gareth Rushgrove, the blog of John Allspaw the SVP of Operations at Etsy and most recently the UK Government Digital Service who are doing some really interesting CD and DevOps projects with the UK government.
About the Book Author
Paul Swartout is a husband, father, dog owner, software development manager and author of “Continuous Delivery and DevOps: A Quickstart Guide”.