The point of Bandaid

I've recently released version 1.0 of Bandaid, a Drush tool to help with patching, but in order for it to be useful, it requires a certain context. So let me explain how we ended up there.

At Reload! we've been using Drush Make for building sites for quite some time. It haven't always been a happy relationship, and in some cases it's been downright a pain.

So after some internal discussion, and looking around, we decided to go over to the OMG ® method.

The OMG method is simple: One Massive Git-repo. Take a site and do a git init in the Drupal root and commit everything (excluding site folders is sites/). We've heard that others use that, including Panthon and Acquia, so it didn't seem like so far out an idea.

The first thing we did was creating a simple Drush deployment command: Deployotron that deploys new code by just Git pulling over ssh (with safety db-dump, running database updates and restarting Apache/Varnish). It's so lightweight that you simply copy it into sites/all/drush (which means that everybody is using the same version for deploying), and set a few options on site aliases in sites/all/drush/<whatever>.aliases.drushrc.php.

Which is all fine and dandy. Fetching a site for your local development environment is just a git clone and drush sql-sync (no waiting for Drush Make) and upgrading modules is just drush pm-update, testing and committing (no rebuilding to ensure that you didn't mess up in the makefile).

Which leads us to the final issue, and the reason for Bandaid: patching modules. When we were discussing how to do OMG, we spend a lot of time talking about the issue, coming to the conclusion that we were all supposed to be big, grown-up and clever developers, capable of doing the Right Thing and documenting what we did, without having tools to enforce it. So we decided to use a simple YAML file to keep track of what patches were applied to a module.

Bandaid expands on this and automates some of the more tedious details when upgrading modules with patches. The idea being that if given a tool that will make a job easier, people will use it, in turn ensuring that it's done consistently.

It currently supplies three commands: bandaid-patch that'll take the URL of a patch, apply it, ask for some extra info for the YAML file, and ensure that the YAML file is created or updated properly. bandaid-tearoff that'll figure out if there's any local modifications to the module, and save them to a patch file. And bandaid-apply that'll apply the patches from the YAML to a fresh version of the module, and if there's was local modifications, attempt to apply that too.

Bandaid wont always save the day, if people mess up the YAML file, or mess with the module without updating the YAML file, you still have to hunt through the site's Git history to try and figure out what happened. But we're working on the assumption that you're working with generally cool people that wont mess with your juju.

And patches can still fail to apply after upgrading the module, but then Bandaid can help with mass-applying patches, if you hand hack the YAML file.

So there you have it.

Blog tags: