Putting Agile Infrastructure into Practice – Agile Executive Episode 007

Last week over at The Agile Executive we finished up the the short series on Agile Infrastructure (part one and part two), addressing the topic of putting Agile Infrastructure into practice:

In this episode, we’re joined again by Andrew Shafer to talk about Agile Infrastructure (or “Agile Operations” as some folks call it).

To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:

• The in problems in IT that cause us to start wanting Agile Infrastructure. The high-level problem is enabling change (that works) more often: configuration drift, intentional complexity, walls of confusion everywhere, hero-driven incentives. Israel also mentions the theory that you have to change up your incentive structures often so that people don’t get locked into incentive-driven thinking vs. “doing the right thing,” so to speak.
• Leading us into the practices, Israel asks Andrew about including the operations folks in the Agile team, just as you do developers, QA, documentation, and so on. This gets into a discussion on “fractal teams.” We then get into other practices and technologies that help with Agile Infrastructure:
• Version control – getting beyond .bak files. You need some kind of version control system. What do you put in there? All your configuration files, to start with. Perhaps your scripts next. Puppet and other tools can help do more. The tools, really, can be the same as used in development: git, subversion, CVS, and so on. In fact, Andrew says you should really use whatever development is using for consistency.
• Always ship trunk
• “Dark launches” – staging the release of features to test back-end tasks before exposing it to the user, and then finally giving the user access to the new system. This lets you test out the impact of the “background” tasks in the production system of new features without exposing it to users.
• An over-arching theme here is to reduce the fixed cost of deployment, trying to get it to zero as much as possible.
• Some other practices: test-driven infr, deploy early/deploy often, tagging everything with who/what/when, time synchronizing, and a few more.

Disclosure: Reductive Labs is a client.