DevOps after reading Phoenix


I’ve recently finished The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win — a rather good use for a long lonely train  trip.

I got lots of ideas and déjà-vu on the situations depicted, so I am posting thoughts on top of what I read.

The return on DevOps is subtle. That may be the harder thing to grasp on this discipline.

Bringing theory of constraints practices that started in the industry to the IT world changes the mindset and the way things get done. A few distinctive aspects of DevOps:

  • Work becomes visible throughout the whole chain
  • Constraints can be identified and dealt with
  • Everything moves faster – including detecting and working out anything wrong

It’s useful to start with proper context. This picture helps.

DevOps and related disciplines, from CollabNet

DevOps and related disciplines, from CollabNet

The Three Ways

The Three Ways are principles from where you can generate DevOps patterns. The first way is the way of the Flow. It means one knows (for you Heinlein fans the right word would be groks) the way value flows from the business to the customer.

The second way is the way of Feedback, adding communication between Ops and Dev.

The third way is the way of Continual Experimentation and Learning. One can improve because now we have feedback from  every small experiment to validate ideas fast.

Fishing The Three Ways

Fishing The Three Ways

You can read a well written description of The Three Ways by Tim Hunter here.

The Deployment pipeline

A core concept for DevOps is the Deployment pipeline, industrializing and removing all technical risks from the whole development to production cycle.

“A deployment pipeline is a single path to production for all changes to a given system., whether to code, infrastructure and environments, database schemas and reference data, or configuration. The deployment pipeline models your process for building, testing, and deploying your systems and is thus a manifestation of the part of your value stream from check-in to release. Using the deployment pipeline, each change to any system is validated to see if it is fit for release, passing through a comprehensive series of automated tests. If it is successful, it becomes available for push-button deployment (with approvals, if required) to testing, staging, and production environments.”

— Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky

Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky, Cutter IT Journal, August 2011

The Delivery Pipeline from Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky (Cutter IT Journal, August 2011)

Deployments become natural, regular and safe. It allows for inverting the wait. That is, IT waiting for the business. So business gets the chance to see working software sooner and within shorter decision windows.

The role of automation

Automation is key for DevOps because it allows for faster time to market. And this changes the way people work and collaborate. For instance, having the same environment from development right up to live production eliminates errors and rework due to disparate environments. This is so obvious that it hurts to think there are still organizations that don’t do it.

Of course there are no free lunches. For the example above one first need to have all configurations under control (not just code, also the environments themselves), otherwise it’s impossible to automate this.

Now think on the impact this approach has for testing. Maybe you don’t catch all errors but you certainly will significantly reduce errors from the Development to Production process itself which cause delays and unproductivity.

When the release cycle reduces to days or even hours you reap another benefit. Introducing new features is fast. Testing scenarios (even with part of your customer base, using A/B testing) is simple.

A neat side effect of automation for the deployment pipeline is that it makes non-authorized changes really hard to sneak in.

And it forces Ops and Dev guys talking each other frequently – probably the biggest benefit of all.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: