7 tools to help you increase dev/prod parity for greater good!
I've been working on making development, staging and production environments as similar as possible recently. The goal of which is threefold (paraphrased from "The Twelve Factor App"):
- Reduce the time gap between when code is written and when it is deployed.
- Reduce the personnel gap: developers who write the code, should also deploy it.
- Reduce the tool gap: the same tools should be used on dev machines and servers.
I find that it has become a lot easier to pull off real dev/prod parity thanks to these tools:
Vagrant (vagrantup.com)
Orchestrates creating, provisioning, starting and destroying of virtual machines. I use it to virtualize my dev environment so I can run Rails apps with exactly the same configuration as the production servers. It also removes the need to install and configure dependencies on my Macbook (nginx, unicorn, redis, elasticsearch, postgresql, ...).
Veewee (github.com/jedi4ever/veewee)
A tool that turns a base *nix image into a Vagrant compatible .box file. You can customize the template scripts to tailor the base box to conform to the conventions you use on your production servers.
Chef solo (opscode.com/chef/)
Complex to understand at first, Chef does simplify provisioning servers or virtual machines a lot. It encourages reusability of "install scripts" (recipes) by packaging them into cookbooks. An awesome side effect of using chef is that you end up with executable documentation of your entire infrastructure in your repository!
I love it because I get to reuse the same cookbooks and recipes for production servers and dev environments. I've chosen for the lightweight chef solo because it saves me from maintaining a chef server and it forces me to check in every piece of data into the repository.
Berkshelf (berkshelf.com)
Berkshelf is to chef cookbooks what Bundler is to ruby gems. It greatly simplifies using (and contributing to) open source chef cookbooks. It is modeled after Bundler so you will feel right at home using it. Comes with a plugin for Vagrant.
You can use these four tools to set up a virtual development environment that is consistent and easy to share between coworkers. This is great by itself, but it only gets better if you add the following tools for production servers:
Fog (fog.io)
Ruby gem with a common interface to (almost) all cloud providers. I love it for managing my Amazon EC2 instances and Rackspace cloud servers. Can fully automate server creation and application deployment if you combine it with:
Capistrano (github.com/capistrano/capistrano)
The traditional deployment tool for Ruby applications. Perhaps slightly unmaintained these days and lacking in documentation for newcomers, but it's been so heavily used that you can find capistrano recipes for just about anything. The multistage extension for example is great to handle multiple environments (demo, staging, production). I've written recipes that leverage Fog to create cloud compute instances, set up DNS and provision the server with chef with the help of the last tool:
Roundsman (github.com/iain/roundsman)
Simple little helper gem that hooks into Capistrano and runs chef-solo on your server. I found the real power of Roundsman is that it enables reusing Capistrano variables in your chef recipes! It will also install ruby and chef on the server if needed.
By combining all these tools you can document the entire environment needed to run your application. It takes time to learn these tools and setup the whole chain, but the reward is totally worth it: Easily get new developers and their machines up to speed. Start and bootstrap cloud servers with a single capistrano command. Excite fellow developers to contribute to the server stack and turn them into devops. Which eliminates the need for the traditionally separate role of sysops.
When developers are the sysops and the dev environment == production environment, you should see a lot less deployment fear and anxiety, which will make continuous deployment easy and eliminate hard to diagnose "production-only" bugs.
Stay tuned for part 2 where I will post code examples and explain how to use these tools.