I just came off my last holiday where I got through reading two books that I wanted to. One of these was the heavy but insightful tome, that I dragged in my suitcase, Continuous Delivery. Before I begin, I should warn you that I work for ThoughtWorks, and that both Jez and Dave (the authors) are and were my colleagues so take this into account with my review.
What I enjoyed
Continuous Delivery is a very practical book that covers a huge range of topics from cover to cover. I feel that they found a good balance between giving just enough advice (and more importantly why) with plenty more references for those who want to find a topic to delve deeply. I felt it really lays down the ground work for many projects (but not all) that need to see the light of day.
I think it’s also great that they not only outlined the practices and tips, but also outlined the principles. It gives the book much more merit and will make sure it stays relevant as tooling and new techniques are invented. On the flip side, they do give enough advice on tooling, and, at least, current up to date advice on how one might achieve things.
I like that the authors expressed their opinons strongly on some of their tooling such as, if you’re going to use a commercial source control system, how it should be used and why, or what the problems with the build process in maven or the limitations of various toolings are.
The book is peppered with war stories. I think I know some of the examples they cite, or at least, heard about it from other people and I think some of them are really strong stories about some of the ways people approach deployment.
What would make it perfect (for me)
I’m not sure if they framed the context of Continuous Delivery enough in terms of the types of applications it’s appropriate for. I know that there’s a current (constant) movement in the startup community of “just putting out there.” I think that is an alternative approach that works for some amount of time (or at least changes some of the testing/feedback process). I think for throw away apps (this one is always hard to judge), it may not be worth investing in the same degree of how much effort you put into the process. I think probably the closest advice but should have been expanded upon was, “be pragmatic about how much you automate.”
One particular headline (out of the very many) grabbed my attention, “Test targets should not fail the build.” After reading that section I think I understood what they meant, but it should have been relabelled, “Failing test targets should not immediately *halt* the build” -> it should still fail the build at the end.
Finally almost all of the chapters, for me, had lots of great advice and in working reaffirmed many of the conversations and thoughts I’ve had over my career. I did find the final chapter about “Risk Management” a bit thin, feeling like it was added at the end and either deserved much more attention or should have been dropped. It felt like it had a different tone, or was written at a different time and couldn’t quite see how it would fit in.
Having said that, these last bits are only minor points in a huge volume of rich information and is essential reading for anyone who cares about their profession.
Putting this into practice
For most of the clients I work on, the clearest and most difficult part of the organisation will be the (im)maturity of the operations side of the organisations. Most are already not set up for success with completely different parallel hierarchies from development and competing goals that go against constant change. I still see this, “last mile” problem being the hardest (at least for me to solve). I am hopeful about the DevOps movement and hope that the IT parts of an organisation can only take it much more seriously. I’m hoping this book shows how more companies can achieve this.
