One of the cool things about what I do, is that I get exposed to some really interesting paradigms. One of the latest is the 12 factor app. It’s an evolution of some of what I have thought in the past, and a radical departure in others.
I’m going to talk about just one of the concepts right now. It was one of the ones that made the least amount of sense to me, until I started to use it. I’m also going to show a concrete example of how to use it in a production system.
Of course, I’m talking about the use of environment variables for application configuration. At first, I though that it was a “nice to have” or perhaps even a little more work then was really needed. Now, I’m going to standardize on this no matter where I deploy, or what I deploy.
I think that there are several reasons to use this tactic, but the one that hit me over the head was simply “No passwords in version control“. You know that you’ve done it. Committed to a repository with your database.yml or wp-config.php all full of DB passwords. It’s almost a necessary evil, right?
So there I was playing around with WordPress, getting it deployed on Heroku and I sat back after figuring this out:
Looking at that gist, one thing became evident to me. The password could not be committed to a repo. I would not have to use arcane git commands again! Well, not to purge passwords at least.
There are a few other benefits as well, ones that have not caused me as much pain as the passwords thing. You can easily manage developer/staging/test/QA/production/live environments by simply calling out the correct config when you build the servers. Need to change a DB password? Just create the new user, spin up boxes using it, deploy your code, and then delete the old user.
Ops does not need to touch code to massage it into the correct environment, and developers do not need to care what the latest username and password for the DB they need is.
Seems like a pretty big win from my point of view..