Ramping on a new project is fun!
Actually, it resembles lighting yourself on fire, running and jumping onto a moving train with jugs of water on it, only to discover the first car has flammable liquids, then the next car, then the next.
Restated: It’s never boring.
So, I’m collaborating with a team writing in Rails 4, and that team’s adopted the 12 Factor App religion. Great! I’ve dabbled in heroku before, and it’s neat to see apps written that way from the first git init.
Anyway, thought I’d jot down just how “easy” it is to get an app running.
-
Install git. Pull the code for the project. Everything’s self-contained from there, right? Er…
-
Install VirtualBox. This will let you create run virtual machines on your development box. (You’ll need about 8GB of RAM installed…you have that, right?)
-
Install Vagrant. This is like a build system for your virtual machines.
-
Install Chef. This is a configuration system for your virtual machines. Once you boot the machine, you run chef to install software, set permissions, etc.
-
Install the vagrant plugins listed in the README.md file.
-
Use the ‘berksfile’ utility that comes with the ‘Chef-DK’ (har!) to ‘vendor’ your dependencies.
-
Vendoring is deep-copying any external dependent applications under your app. That way, you’re insulated from change should someone go and upgrade one of those dependencies to an incompatible version. It’s one way of handling ‘DLL Hell’ situations. Another (more draconian) method is #golang’s method of just compiling everything into one static executable.
-
Do ‘vagrant up’ and wait a few minutes for it to create your configured running machine from scratch.
When it works, it’s fricking beautiful. You’ve eliminated whole classes of bugs: System configuration vagaries, OS package differences. All developers are using the same system to develop, test, and deploy.
When you’re a n00b, it’s a bit daunting, but I’m liking it. If nothing else, it lets me develop on my OS of choice, then run on a different target–usually the same one as production.