I read this article from mig5.net about 'Drupal deployments & workflows with version control, drush_make, and Aegir'. I am impressed by the efficiency of the workflow described here, and I really want to implement this. I read it again and again, but one thing won't get clear to me.

How do you, while developing websites, get your changes into the next build? When you find out you need an extra module, how can you get this in the next build when the (for example contrib) module isn't controlled in git? Do you need to edit your .make file every time you want to add a module, library etc.?

Thanks in advance.

2 Answers 2


Yes. The short answer is you update your Drush make file to point to the new version of the module you want to be included in your new platform(build).

In your drush make file you would include the version of each module you are including in your platform build. So views for example would look like this.

projects[views][subdir] = "contrib"
projects[views][version] = "3.4"

Now if you want to update to the new version of Views module you would update your make file to something like this.

projects[views][subdir] = "contrib"
projects[views][version] = "3.5"

Then build a new platform in Aegir using this updated drush make file. Then you would migrate the site to the new platform and Aegir will do the update for you.

It's a pretty slick workflow. I keep all of my drush make files in a repo called builds so I can have a record of each build of a project. Hope that helps.

  • Why is the build in the article called 'drupal-6.14_build_2009102601'? If I'm right, it's the application of Mig5, so wouldn't it be more logic to call it 'mig5_build_2009102601'? This workflow also involves you get a huge list of platforms when you're developing more sites, isn't it?
    – user6503
    Commented Oct 10, 2012 at 9:50
  • 1
    Sure, but so does Capistrano-based builds. A smart engineer would implement automatic cleanup of old platforms that no longer have any sites on them (you can automate deletion of platforms in Aegir). And yes, you can call the platform name anything you like. These days I am even more brutal with my naming and simply use the serialised number eg '2009102601', because I find it doesn't matter so much what platform the application is on (it changes all the time so who cares)
    – mig5
    Commented Oct 10, 2012 at 11:13
  • Okay, but when you have to roll back a change you don't have an idea to which platform to migrate to, because you didn't attach a descriptive alias to it (the date, but not a site-name)...
    – user6503
    Commented Oct 10, 2012 at 13:40
  • And am I able to auto-delete platforms with a module like Auto Expire? A problem is the fact that this module would also (try to) delete the latest released platform (if the site hasn't changed for a while).
    – user6503
    Commented Oct 10, 2012 at 13:56

Bob beat me to it :) but in response to this and your email you sent me, yes indeed this is the correct procedure. Treat your Drush makefile as the 'blueprint' of your application.

Work away in development manually / clone your live site and manually 'drush up' or 'drush dl' a module and test that everything works as expected.

Then fold that new module/updated version into your makefile, build a new platform each time the makefile is updated, and use the 'Migrate' task to 'upgrade' your application onto the target platform.

If something goes wrong during the upgrade (e.g during the drush updatedb which occurs during a Migration to apply schema updates in your database), Aegir will, in most cases, automatically roll back to the previous platform, which is the appeal of such a system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.