ansible

Some places where I've worked have used SVN for version control, and while the supposed simplicity and centralization of SVN can be nice in certain situations, SVN can't hold a torch to Git's speed, flexibility, and ubiquity (nowadays) for source control. Not to mention SVN doesn't have real tags or branches, just quasi-directories that can easily be mangled into a horrific mess (I see this quite often).

I've had to use some incredibly large (10,000+ revisions, 2GB+ total size) SVN repositories, and while I've managed them using git svn sometimes (see Switching an SVN repository to Git using git svn), it's much nicer to be able to migrate the entire team from SVN to Git so everyone can work on the repository much more efficiently.

The Drupal community uses IRC extensively for collaboration and community building. A permanent and ever-helpful fixture of the official #drupal-* IRC channels, and in the Drupal community itself, is the humble Druplicon bot. Druplicon is a Drupal-based IRC bot that was created in 2005, and is still going strong as part of the Bot module for Drupal.

Bots like Druplicon do a lot of nice things—they can remind people of things after they were away for a while, they can store facts, track karma, throw people virtual beers, store and retrieve helpful facts, and relay important information. For example, when a build fails in Jenkins, a bot can post a message in IRC. Similarly, if a server goes down, or is under heavy load, the bot could post a message.

I've published the first portion of a book I've been writing, Ansible for DevOps. This is my first-ever book, and I've written a little about the process of writing on Server Check.in's blog: Self-publishing my first technical book on LeanPub.

I'm excited about the early feedback I've already received—and I haven't even finished writing half the book! I'm hoping to finish the first complete draft of the book (and continue publishing it in stages on LeanPub) by summer 2014.

Lately, I've been working a lot with Ansible, a simple but powerful infrastructure management platform. I now use Ansible playbooks and ad-hoc commands to manage all of Midwestern Mac's infrastructure (this site, Hosted Apache Solr, Server Check.in, and many ancillary servers), and as a result, I've started using Ansible for pretty much any kind of work I need to do in development—including configuring my own Mac, and developing with Drupal 8.

Meet Ansible

For those who haven't heard of Ansible before, it's often described as being a little like Puppet or Chef, used for configuration management. You define the configuration of a server, and Ansible makes sure the server is configured as defined. But Ansible goes quite a bit further—it's also great for deploying applications (especially in tandem with tools like Jenkins), running commands on servers, and day-to-day management of a few, hundreds, or even thousands, of servers—it's an end-to-end configuration management tool. Ansible also has a great, and rapidly-growing community, building it up and making it markedly better every release.

Ansible uses YAML to define configuration (just like Drupal 8!), and is relatively easy to pick up, especially if you already have some experience on the command line. You can read more about it in a book I'm writing, Ansible for DevOps, and hopefully, I'll be able to tell you more about Ansible in person at DrupalCon Austin—I've submitted a session titled DevOps for Humans: Ansible for Drupal Deployment Victory! (please leave a comment and let me know what you want to hear!).

Drupal development VM (Vagrant + Ansible)

I used to use MAMP (a simple-to-install Apache + MySQL + PHP setup for Macs) for all my development, which made adding virtual hosts to Apache relatively simple. However, there are many downsides to developing with MAMP—I could never configure things like drush, APC, the version of PHP, MySQL, or auxiliary tools like XDebug and Solr, exactly how I wanted or needed them.