Mavelous

Today, I come to you with a co-author. Since February, I’ve been working with Mark Thias on a Continuous Delivery (CD) consulting engagement.

This is the third in a series of posts I’m making detailing my setting up a Puppet master/slave pair of servers on Linode. If you haven’t seen them yet, go check out my first and second posts about my Puppet servers.

A few months ago, I published a post about using Puppet to manage infrastructure. As my company grows, I’m finding it more important to ensure that all of my servers are managed in a sane manner. To me, this includes ensuring that if one of my servers ever goes down, or the data center it’s in gets smashed by a meteor, I could theoretically be back up and running just by migrating to another data center.

One of the best things to come out of the Continuous Delivery movement is the concept of infrastructure as code. This is the idea that you should treat your servers in the same manner that you treat the programs you write to put on those servers. In other words, you should be able to programmatically specify what type of operating system you want on your server, which packages should be installed, and how they should be configured. Further, all of that should be code, and it should be stored in your version control system and treated with the same rigor as you treat the other code you write.

As an Agile Coach with a past history as a developer, my goal is to get my clients building actual software quickly. Often, I would prefer not to do anything close to a Sprint Zero, because I’ve never seen a Sprint Zero that’s about delivering working software. Just as often, I can’t avoid it, because the clients I work with simply aren’t set up to not do one.