community.aegirproject.org

We’re a software company that has a SAAS offering built on top of Drupal. We use (and LOVE) Aegir to manage instance deployments as well as development and deployment workflow. For a while, we’ve had a deployment workflow running smoothly with Aegir, based on the concepts presented by mig5 in his excellent article on the subject http://community.aegirproject.org/article-archive/drupal-deployments-wor...

However, we found that we were spending lots of time manually setting up platforms, waiting for sites to migrate, etc. It was a waste of time, and also meant that we didn’t test our progress in a pre-production environment as often as we should. I read with great interest another of mig5’s articles on continuous deployment with Jenkins, but this seemed a bit overkill for what we needed to do, and fairly complicated to set up.

So we set about creating our own zero-touch deployment approach which I’d like to share with everyone here in case it can help someone and to get your feedback. It’s quite simple, and consists of 2 drush scripts, a bash script, and a makefile.

Before you get started, it’s best to re-read mig5’s article on deployment workflows with version control and aegir, since what we’re doing is an extension of this idea. I’m also going to assume you’ve got an existing aegir platform up and running with command line access, you’ve got a test site (or sites) running on aegir, and your platform code is all stored in version control.

Start with a makefile

To begin, you’ll want to setup a makefile for your build, and make sure that it’s working correctly to build your platform. Here’s our makefile as an example. We cheated a little bit compared to the “pure” approach to makefiles, as we’ve got our entire sites/all directory stored in version control. We’ve got lots of custom and contrib modules, some of which we’ve modified, and it was easier to do it this way rather than try to set up individual repos for each module and fetch contrib ones individually in the makefile. Here's our makefile as an example. The root of our repo starts at sites/all, so this is where we will pull in all the code (cheating, using the "library" function of make, and telling make to overwrite the one file that is already there by default)

If, like us, you’re having a bit of trouble getting git setup correctly, make sure that you generate ssh keys with the aegir user on your primary platform, add the aegir public ssh key to your github/bitbucket repo, and then do a git clone on the command line to test everything out before you let aegir do it for you.

With this in place, you should now have an aegir setup where in the frontend, you can easily create a new platform off of your develop branch (or whatever branch you want to use for automatic deployments), and then again in the front-end, migrate your test site(s) to the new platform.

Now comes the fun part – automating this!

Here are the steps we want to automate: 1. Check if there’s been an update to our platform code 2. Create a new platform based on the updated code 3. Migrate our test site to the new platform 4. Clean up any unused platforms

Here’s the bash script that does all of these steps.

In order to automate this so that it runs at a regular interval (we check every 10 minutes), as the aegir user add it to your crontab using crontab –e, and add the following line
*/10 * * * * /var/aegir/makes/autoplatform.sh

Now let’s go through what we’re doing in each of these steps:

1. Check if there’s been an update to our platform code

We keep a local version of our platform code in /var/aegir/repo/develop/ so that we can use it is as a base for comparison to see if the remote code has changed. In theory, it would have been cleaner to setup a commit hook which would then trigger our updates, but this is the “lite” version, so we really wanted to stick with stuff that could be easily integrated into a shells script ;-)

We first check for remote updates, and then perform a diff to see if there are differences between the remote and the local versions. Using the --quiet switch allows us to simply check an exit code to see if diff returns something or not before continuing. Once we know that we need to build a new platform, we also need to update our local copy of the repo so that we’re in sync with the remote version and we don’t keep triggering a build of a new platform!

2. Create a new platform based on the updated code

Now that we know that the code has been updated, we can tell aegir to build us a new platform. The makefile has all the details about how to build out the platform and will get the sources for us, so we just need to create the platform in the backend, then import it into the front-end (this part is directly borrowed from mig5’s setup) We set up an environment variable with our (automatically generated) platform name, which simplifies the process of creating the platform

3. Migrate our test site to the new platform

There’s currently no easy way to migrate a site from the command line (See http://drupal.org/node/1003536 )

But Drush script to the rescue! The following drush script takes as arguments the name of the site to migrate, and the name of the target platform, and looks up all the information needed to add a hosting migrate task to the front-end, and migrate the site on the backend. Since aegir tasks happen asynchronously, we also added a waiting period of up to 10 minutes for the platform to be available, since in the case of our automated deployment, we need to give it time to build

Here’s the drush script (remember to chmod u+x it so that it can be run from the shell)

To run it, call it within the hostmaster context
/var/aegir/makes/migrate.drush @hostmaster SITE_TO_MIGRATE  TARGET_PLATFORM

4. Clean up any unused platforms

Finally, we’ll want to clean up old platforms we’ve already migrated away from, otherwise we’ll clutter up the interface (and our disk space!)

Again, there’s no easy way to do this from command line (http://community.aegirproject.org/discuss/there-way-delete-platform-comm...), so we wrote another drush script to handle it

Again, you’ll want to call it from within the hostmaster context
cleanup.drush @hostmaster PLATFORM_PREFIX

Please feel free to provide suggestions or improvements, or move it to the handbook if it is helpful for others!