Book Review: Continuous Delivery and DevOps: A Quickstart Guide (3 of 3)

In finishing up the book review and notes I took, the topics of CD and DevOps culture and behaviors, hurdles to look out for, and measuring success are covered.

I took almost twice as many notes in this section as I did in the previous sections. I haven’t looked at the actual page breakdown for how I broke down the book for my three reviews. This last section did have another chapter but I think it could be that these topics are the ones I least expected to see in a DevOps book so I took the most notes about them. Having said that, I am just giving highlights from the book and my notes, instead of mostly just typing my notes like the last post.

Implementing and transitioning to a CD and DevOps  is as much about the culture and behaviors of the individuals and organization as it is about the tools, processes, and procedures used. Some of the sub topics covered previously in the book are reiterated in this section. The sub topics include “Open, honest, and courageous dialogue,” “Encouraging and embracing collaboration,” “Innovation and accountability,” “the blame culture,” “building trust,” “rewarding good behaviors and success,” and “Embracing Change and reducing risk.”

Having big screens with key metrics and information is again stressed. All of this helps with the “human side” of implementing CD and DevOps.

There are some common hurdles to look out for with any CD and DevOps implementation. Some of these were mentioned earlier in the book as well. There are individuals who find change difficult and will resist any change, including accepting the CD and DevOps ways of working. Some people will think that change is not happening quick enough. Corporate processes and red tape may get in the way. You might not have the right people and need to recruit new employees.

The “hurdles to look out for” section describes three groups of people– Innovators, Followers, and Laggards. The majority of the people will be in the first two groups and most of your attention should be focused on them. The Laggards will eventually join or get out of the way as they see the positive effects of CD and DevOps. Other hurdles to look out for is the affect of “Outsiders” who you don’t have influence over, geographically different teams or individuals, making sure automation is repeatable and consistent so the process is trusted, and like the previous section mentions, recruitment of those with a CD and DevOps mindset.

The transition from a “Legacy” way of doing things to a CD and DevOps organization started with a goal and vision. Being able to state how far along you are to reaching that goal and vision is important, as well as knowing when you have reached it. Measuring effective engineering best practices is encouraged. This means measuring code quality, code complexity and unit test coverage analysis. Looking at comments vs. code and commit rates is also effective measuring strategies. It is important to start this upfront and tweak as you go.

The platform needs to be measured, as well as the overall effectiveness of CD and DevOps. “Environment issues” might be blamed for code or delivery problems without proof. Running automated tests and monitoring, including health checks, gives the platform some credibility to the developers and engineers. Measuring improvements in efficiency and throughput could be done by reporting the following metrics–
– number of deployments completed
– time taken to get from release candidate to production
– Number of release candidates built
– A league table of software components which are released
– A list of the unique software components going through the CD pipeline
– cost of each release (if calculable)
– additional revenue due to each release (if calculable)

The last section before the summary is “Inspect, adapt, and drive forward.” The dedicated implementation team doesn’t need to remain dedicated once the goal and vision has been achieved. That does not mean the process is complete. CD and DevOps needs continuous improvements, so the dedicated implementation team moves more into an advisory role as the larger team takes over day to day improvements and enhancements.

I won’t write out my notes for the summary. I find it interesting that that last point is to “have fun” and “don’t give up.” Good advice for anything worth while.

Book Review: Continuous Deliver and DevOps: A Quickstart Guide (1 of 3)

To further my DevOps knowledge and abilities I have been reading Continuous Deliver and DevOps: A Quickstart Guide by Paul Swartout. I’m about half way through it and wanted to get some thoughts down about the content and the book itself.

I actually started reading this book before I read the whole title. I was just looking for a DevOps book and this was the first one that popped up in the online library I was searching in. The further along I get the more I understand why it is called “A Quickstart Guide.” That doesn’t mean it can’t be valuable. It is just lacking some depth that I was looking for.

The book introduces a fictional company called Acme, and goes through the growth of a small start-up the eventually gets acquired by a larger company. Using the fictional company does serve an effective purpose to illustrate the growth and transition a company could make to Continuous Delivery (CD) and DevOps. Before reading the book I didn’t think of what it took to transition from “Legacy” development to CD and DevOps. I was just under the impression a company was one way or the other and never thought of what it took to make the transition. I’m grateful for reading the book for that reason alone. I also saw the impact DevOps has on the whole company. Sales and marketing teams have to adjust their practice and proceeds to match what DevOps is doing.

Managing a typical transition could look like this, with points to consider along the way (from pg 68 of the book)–

  1. Define a goal and vision
  2. Communicate, communicate, communicate
  3. It will change the business so make sure it has the recognition
  4. Form a dedicated team
  5. Evangelism is good PR
  6. It’s not all free
  7. You are not alone (in a good way)

What I got out of the first half of the book is that there is a distinct contrast between a small and nimble company and a potentially clunky large enterprise. Each has its strengths and weaknesses, and the purpose of CD and DevOps is to create an environment that draws on the strengths of both worlds.

So the first part of the book illustrates the transition of using development and operations practices for developing “legacy” code, (code that is large, all packaged together, and released together,) to that of agile code development (utilizing CD and DevOps principles.) In previewing the second part of the book it seems to be covering how CD and DevOps is delivering code, outlines the software engineering fundamentals and best practices, and the tools used to reach your end goal. I’ll create another post in the new few days on that.

I am interested in learning the furthering my knowledge on the tools side of DevOps but now I know I need to broaden my vision and understand how the tools fit in and affect the rest of the process and company.