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 Delivery and DevOps: A Quickstart Guide (2 of 3)

In the first post of my review and some notes about the book “Continuous Delivery and DevOps: A Quickstart Guide,” the topics of how an organizational transforms itself from a “Legacy Code” organization into a DevOps organization was covered. This post is about the tools used and I found to be more notes than review of the content.

CD and DevOps is about removing waste and inefficiency.  “It is based on the premise that quality software can be developed, built, tested, and shipped very quickly, many times in quick succession — ideally in hours or days at the most.”

Good software engineering fundamentals are needed. Some fundamentals outlined in the book are–
– Always use source control
– Commit small code changes frequently
– Do not make code overly complex and keep it documented
– If you have automated tests, run them frequently
– Run continuous integration (CI) frequently, if you have it
– Use regular code review
– Do not be afraid of having tests that fail or other finding fault in your code.

Some strategies and goals included– “Never break your consumer,” Open and honest peer working practices, Fail Fast and often, Automated build and testing, and CI. Almost all of these topics can be directly applied to Ops practices.

Component based architecture is where code and services are broken down into discrete modules or components that are loosely coupled. Using component based architecture reduces the pain and overhead of releases.

Use Layers of abstraction to reduce dependencies which require two components to be deployed together. This also simplifies processes and reduces downtime.

Getting the right amount of environments is also important. The fewer the better, meaning if you can get away with just two then do it. For larger organizations the following number of environments is suggested–
– Dev
– CI
– Pre-production (UAT/Spot Check/[load testing, something not stated in the book])
– Production

Later the book also talks about using a “Like Live” environment to develop against. This environment might be a virtual copy on your desktop, but is essentially what is currently running in production.

The same binary should be used across all environments. This might mean you will need to load configurations specific to the environment at deploy time or package time. A repository should be used to version and store the binaries.

There is a long section about CD tooling. What it should do and how it should do it. The book mentions there is not a lot of commercial tools out there, but that might not be so true now. It suggested building your own. The CD tool seems to be what orchestrates everything. Being able to access source code and build binaries, do deployments, record every action taken, be able display how much it is used, etc.

Automated provisioning is being able to programmatically create the infrastructure or platform for deployments, IaaS and PaaS, with all the needed configurations. This is helpful for no-downtime deployments. This is something that should be included in the CD tooling.

No-downtime deployments are critical for real time systems that customers count on. Downtime could be very impactful on the business and the companies reputation.

Everything should be monitored and everyone should have access to the monitoring information. It will get used more if it is all in one place and easy to get to.

This section also talks about simple manual processes. Not everything has to be solved by software. Some electronic solution might be overkill and counter productive.

Since the tooling was the area I was most interested in I was hoping for more examples of the tools that are actually used and how to implement them. The 10,000 foot view is also helpful for the amount of time I took to consume it.

My next post will cover the last few chapters of the book that covers culture and behaviors, hurdles to look out for, and measuring success.

Pet Rabbit

My family has loved our pet rabbit, George. (I used to be able to say pet rabbits but we are down to one for the moment.) With some family members being allergic to animals George has been the perfect outside pet, which we allow inside occasionally. George is a Himalayan. They are known to be very docile and kid friendly. He digs some, but isn’t able to make the same tunnels and doesn’t have the same digging capacity as some of our former pet rabbits did. We love seeing him outside eating grass and trying to dig through weed barrier. George isn’t perfect but has made our family happier just by being around. (Isn’t that how every family member should be?)

Jealous God

During Sunday School yesterday a side topic of the difference of “Jealousy and Envy” came up. Though we didn’t talk much about the difference, we mostly talked about dealing with jealous feelings, I did a quick Internet search on what the difference was. While doing the search I remember reading that God was a jealous God. That bothered me when I read it in years past because I thought it is not good to be jealous. I didn’t find a good answer for it at the time but did better understand it after I read the meaning of Jealousy in one of the search results.

The sentence I read was, “Jealousy occurs when something we already possess (usually a special relationship) is threatened by a third person.” (https://www.psychologytoday.com/blog/joy-and-pain/201401/what-is-the-difference-between-envy-and-jealousy)

I didn’t read the whole page because that alone helped me understand the meaning of a Jealous God. God has a special relationship with us and when something threatens that relationship he is jealous. As we discussed during Sunday School, when we have our own feelings of jealousy or envy, we must understand where those feelings are coming from. Are those feelings healthy, and if they are then what must we do to maintain or obtain the relationship (or item, or blessing) we desire?

Great neighbors!

It is awesome to live in a neighborhood where we look out for each other, support each other, and are so generous. I was looking for some old computers so I could setup a home computer lab. Two families responded to a Facebook post my wife made for me, (yeah I should probably get my own account,) and one of them had just what I needed! On top of that they wouldn’t accept any money for them when I came to pick them up! Thanks to the family that will remain anonymous for now.

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.