The publisher, Packt, gave me a review copy of this book.
Continuous Delivery and DevOps: A Quickstart Guide by Paul Swartout.
http://www.packtpub.com/devops-quickstart-guide/book
I am personally interested in DevOps. I have done both development and operations – and like being of value in both. I am immersed in software development – enterprise software at the job, and startup-type stuff as a hobby. Delivering is important. I am a fan of startups, where building things quickly and well is important. I am also aware of the problems raised by the contrasting priorities of Development and Operations.
The book opens with a story of a fictional “web-based software business” – or “cloud or SaaS,” since those types of setups are driving the culture and need for Continuous Delivery and DevOps. It walks through its evolution from a small shop to a mature organization through an acquisition. This allows the narrative to illustrate the conditions and problems that are specific to both types of company setups. The software delivery flow goes through three levels: a very simple one (Have a great idea -> Develop it -> Deploy it), an overly complicated one, and finally a reasonable flow given the evolution of the company. I feel the first chapter sets the tone that the book is trying to talk to everyone but might miss out on reaching to some audiences who won’t be able to relate. For example, while I believe the book should be readable by a non-technical project manager, it drops some jargon in an example.
The story moves on to identifying the “Elephant in the Room” and finding the causes of problems in software delivery by engaging the people involved. The investigation techniques are Value Stream Mapping, Retrospectives, and the Timeline Game – actual games. After the information is gathered, plans are made to setting and communicating the goals and vision, to lead the plan of attack on implementing Continuous Delivery and DevOps. This is done by standardizing the vocabulary and language (watch the jargon!), operating as a business change project, working with a dedicated team, acting as an evangelist, making decisions with courage, understanding the cost of change, and seeking advice from those with similar experience. I find that these actions, while all good, belong to different roles and am not sure as to who the book is talking to.
After the setup, implementation is next. This is using source control (which is already standardized in many places, with the help of services like GitHub that promote it); keeping changes small, frequent and simple; having clean consumer/provider separation (software architecture advice, actually); open and honest peer working practices (tied up with corporate culture); failing fast through test-driven development; automated building and testing and continuous integration. The story then goes back out to architecture: how component-based architecture with loosely-coupled pieces works better, separated by layers of abstraction – clearly aimed at the software architect role. This is followed by advice on environments, tooling, provisioning systems and monitoring – a common responsibility of Development and Operations.
The book then turns around to talk about culture and behaviors – a chapter that reads like an Agile Methodology advocacy mixed with Software Engineering Management and general management. A key point here is getting rid of a culture of blame, and bring it up to a culture of trust. While this is important for any organization, the speed DevOps brings highlights this need.
The last chapters talks about the hurdles that need to be overcome and ways to overcome them, and then measuring success and staying successful. This part reads like a software engineering management advice book, and not specific to Continuous Delivery and DevOps.
My main criticism of the book is that it rapidly switches between technical and non-technical topics. It doesn’t seem too sure of which audience it audience it wants to address. I believe that it would have been more effective if the technical and non-technical parts were separated into different sections such that the reader can easily choose the relevant topic. A lesser criticism is that the book often drifts into advocacy or evangelizing the need for Continuous Development and DevOps, when it may already be preaching to the choir who already believes in the concept.
The benefit of the book is that it gives some good starting points that the aspiring practitioner can take action on.
