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.
Alright. So. I've got an extensive background as a developer. I automate things. All of the things. Anything I have to do more than once needs to be automated. It's an OCD thing. In all of my recent programming jobs, I've worked to replace myself with a very small shell script.
Last weekend, I drove down to Indianapolis for Agile Coach Camp. I didn't find out about it until Wednesday afternoon, but by early Friday morning, I was on my way to my first major coaching networking/learning meeting.