Learning From Continuous Delivery

We only ship our product three times a year and while we do fairly frequent builds, we don’t have a continuous delivery deployment system.  Since we don’t do it, it might seem that I shouldn’t bother with learning about continuous delivery and integration, but I try to keep up with new developments of this sort and so I’ve read and learned a bit about these things.  The interesting thing is that, as with many things that don’t seem directly applicable to my day to day work, I have been able to use ideas from this to help improve things.  A lesson or skill learned can be very helpful even if it isn’t directly about the work you are doing.

For example, due to a recent reorganization effort in our company, I am now part of a new team which is combining together some of the automation work of several previously separate teams.  I have been thinking about how we should go about consolidating and running these various tests and one of the ideas that I will be using is drawn from the continuous delivery world.  This is the idea of what is sometimes called rings of deployment or flighting.  The (very) quick summary of this is that you expose new code to a small group of people first and then if everything goes well you gradually roll it out to larger and larger groups of your customers.

Since we only ship once every few months it might seem the idea of rings of deployment doesn’t apply, but in fact I think the idea will fit in very nicely with out development process.  However, instead of thinking about gradually larger groups of customers we’ll structure it in terms of gradually exposing parts of the code to larger and larger rings of code.  So for example if we have changes in a particular component we will run a set of tests particular to that component.  These tests check if anything has broken directly within the component itself. If they pass we will then build that component against the latest ‘certified’ build and run some integration tests.  These tests check if the component changes broke anything the larger system relies on.  If those pass we can then check if everything works when the component is integrated with the latest combined builds to check that the build pipeline won’t break.  At that point we can start to consume those changes in all the developer builds and start certifying a new package which is the final integration step.

Once you add in the ability to use feature flags and beta features we can actually have a pretty sophisticated deployment chain that gives us a lot of information on where failures are coming from and that also allows us to limit the number of people affected by breaking changes.  If there is a breaking issue in a component, that will only affect teams working on that component and if there is a breaking issue in the integration that will only affect the people consuming the latest version of the component for their own integration testing.  By gradually exposing the changes to integrate with more and more of the code base, we are able to reduce the impact on the number of developers and testers affected by breakages.

I know this isn’t rings of deployment in a strict sense and the purpose of this article isn’t to define that clearly.  The point I want to make is that I probably would not have taken the approach that I am to the overall structure of the automation if I hadn’t heard of the idea of rings of deployment.  By learning new things (even things that might seem like they don’t really apply to my context) I have been able to make translations in my head and let ideas create new ideas and come up with something better.

Never stop learning!


Leave a Comment

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 )

Connecting to %s