Main menu

Drush make, Aegir and Dropbox

7 February 2011

These three tools (drush make, Aegir and Dropbox) have come together to produce a release system that means I don't have to ssh into a remote server to deploy a new version of site. This means that I can do releases really, really simply, and actually with nothing more than a web browser1. Let me explain:

Drush make

If you aren't using Drush make, then you should look into it. Essentially you specify a manifest of all the code that makes up you project and then you can ask drush make to assemble the code for you. It has some really nice features, like being able to apply patches and checkout code from CVS, git, etc.
Its real power comes from the ability to recursively make projects. If one of the projects contains a make file, then drush make will parse that and use that manifest of code additionally. The main use for this is to pop a make file in your install profile, and then use that to specify all the projects and patches that your profile will need. You can then have a 'stub' make file whose only job is to download Drupal core, and your profile. For example, the stub install profile for this very site looks like this:

Line 4 just tells drush make to download Drupal, and then the rest are to get the install profile, which happens to live on github in a git repo (a private github repo mind you.)
From there drush make finds the make file in the profile, and parses that and goes on to download all the code needed for the entire site.

Aegir and make files

I'm not sure when the feature was introduced, but Aegir can use make files create new platforms for sites. Point Aegir at a local copy of a make file and it'll go away and run drush make for you and add the platform to Aegir. This is great! If you can get the stub make file (remember that was the simple one above) onto the server running Aegir, then you can provision a platform with your profile available easily. However, there is still the step of getting the make file onto the server...

Dropbox

Dropbox is the rising star of the file sharing world. It makes syncing files between computers painfully simple. So why not onto a server too?
Following the instructions to install Dropbox headless you can get set up with Dropbox really simply and start automatically syncing files to your Aegir server. So pop your stub make file in your Dropbox and it'll get synced over to your Aegir server in no time, you can then provision a platform in the Aegir frontend!

Putting it all together

So, practically how do we use this? Well, suppose that we want to work on a new feature of this very site. We would work busily away in git, committing, branching, merging, adding new projects or patches to the profile's make file, all the fun stuff, then when we're good to go, we'd make a tag in the git repo. Then we just open up our stub make file in Dropbox, and change the release tag to our new tag. Give Dropbox a few moments to sync, which is likely less than the time it takes to log into our Aegir instance. Move over to Aegir, provision the new platform based on the make file, and then migrate the site over to use the new code. All lovely, and not a ssh login in sight 2.

Drawbacks

I'm still not entirely convinced of the workflow using drush make, it seems that you have to rebuild your code base entirely quite frequently, which is quite a waste of time and bandwidth. There is an issue on drupal.org to enable rebuilding of makes though that seems to have stalled. It's also quite a big shift in how you work, and you don't always have everything in a version control system, so you can't make random hacks to everything and then just revert them. So, there are some wrinkles that need to be worked out, but it's the future I tell you!

It's likely that one would still want to other tools, like a local development environment or a local filesystem, but you don't technically need these things for this process. ↩

Technically we could do our git work using the github web interface, and edit the Dropbox file using theirs, otherwise, yes, we'd probably be using ssh for git operations. Not for logging into production machines though! ↩

About the author

Steven has a wealth of experience building Drupal-based websites and tools associated with them. He is a maintainer of the Aegir project and has contributed to many other projects on Drupal.org. He is currently our infrastructure lead and is a lead architect on many of our projects.

He is a Master of Mathematics graduate from the University of Warwick and got involved in Drupal creating a website for the Maths society there.

Comments

Hey, with the point you made about "not being able to store random hacks" etc.. the "Drush Make Way" would be to have a patch file referenced in the make file, and have it applied when the platform is built. That said, I still haven't mastered this :P

Yeah you can add patches easily enough, and indeed we do, but I'm talking about when you're developing, you might want to quickly hack Drupal core to add a print_r to a function or two. If the entire codebase is in a VCS then you can just revert those hacks that you don't want really simply.

You'd probably still want a separate platform for hacking on, but how about just using a local git repo for quick hacks?

cd myplatform
git init
git add .
git commit -am"original files"

patch, then test, then use git to revert changes. It's a bit of a faff but could be partially scripted.

One other suggestion, and one I'm leaning towards myself is to pull the whole platform from VCS. So, in your makefile pull projects from drupal.org repos (CVS is safest for now, git in a couple of weeks hopefully :) and use drush's --working-copy flag, now you can easily revert changes. And as a bonus you can easily generate patches when you fix something.

Not sure if you realized but just didn't touch on it: the makefile you specify doesn't need to be local: it can be a URL to a remote location too. So you might not even need Dropbox here (I just reference my stub file direct from github over HTTP)

This is built into Drush make itself (remote makefiles) so we just leverage that.

Still haven't done the setup, so I imagine I might discover that's it's impossible once I get started, but any thoughts? Dropbox doesn't offer rsa-key authentication, and I believe that TrueCrypt does, so that's my logic -- I'd like a way to control who gets access in an organizations (plus aegir users would get access).

Anyhow, thanks again!

Comments on this article are now closed, if you want to give us feeback you can use our contact form instead.