Most of you have probably heard the term "Technical Debt". It's basically those bugs in a code base that add up after messy quickfixes that don't involve the proper amount of testing and refactoring. The @TheKeyboard blog recently coined a the term "Infrastructure as Debt" to bring awareness to the even nastier task of cleaning up the issues related to your environment and the process of moving code from deployment to production.

I'll summarize some of the issues he highlighted. By fixing these, you can 'pay off' your Infrastructure Debt:

Developers each using a different 'preferred' development environment causes code to be out of sync. You can institute the same environment for all devs or let them use identical virtual machines with their preferred tools.

The deployment process needs to be controlled and standardized through automation. Different deployment processes lead to Infrastructure Debt.

Elaborating on the second point:

I really think there is one rule: if you cannot do your deployments with one command then you are DOING IT WRONG. If you can type the commands you are doing into a shell then you can script them so you don’t have to type them in again. If you can script deployment, then you can automate deployment. If you can automate deployment then you now have a consistent and repeatable process that will behave the same way every single time you deploy. --Chris Hartjes

Tools like
Capistrano,
Phing (PHP), or
Jenkins can help you here. It's important, Hartjes says, that you examine your process beyond the coding. Check out the post if you want some more details on this Infrastructure Debt thing.