Aegir in Git-based deployment models

Events happening in the community are now at Drupal community events on www.drupal.org.
crea's picture

I currently deploy my changes from dev to production using Git. I find Git a priceless tool for managing my codebase and am seeking ways to automate my deployment tasks without writing too many shell scripts involving drush etc. Does anyone use Aegir as a tool to automate git-based deployment ? Please share your experiences

Comments

I haven't set it up yet but...

whatdoesitwant's picture

Adrian Simmons has a good tip (#2) at perlucida.com.
I am also keeping an eye on Victor Kane's awebfactory. He suggested that he might write about this.
Related resources are mig5's video and his 3 steps in his article on setting up a feature server in five seconds.

Update:
comment by Victor Kane at his blog awebfactory

Right now I am creating a repository for each Aegir platform
This repository can be local, and I then do a "git push origin master" to github.com, but gitorious would work (never used it though).

Not quite

adrinux's picture

My tip #2 is related but not quite the same thing. It's more to do with development than deployment.

@crea I assume you're talking about push/pulling all the code over to production, you probably even use a vendor branch and merge in updates before that :)

That way of working doesn't really sit well with aegir. Instead you need to think in terms of building platforms with drush+drush_make. It's the drush_make 'build' files together with any custom code (modules/themes/patches) that live in your git repo. To include updates or new custom code you build a new instance of your platform then migrate your site/sites from the old version of the platform to the new version.

For the moment you can build a duplicate platform on the production server and migrate, but the intention is for aegir to be able to deal with deployment, and work is already underway for that.

mig5 has written a lot about this sort of stuff on his blog, and talks of this as being a paradigm shift. You have to start thinking completely differently about how you're deploying sites. Get on #aegir on irc.freenode.net if you want to talk about this some more.

@adrinux My setup consists of

crea's picture

@adrinux
My setup consists of several things
1) "unmodified" repo which contains Drupal core and modules I get from D.o.
2) "dev" repo which adds my patches, and own modules on top of 1. Also this repo contains my development code in different branches that I merge in from time to time.
3) "production" and "hub" repos. "production" repo pulls from "hub" as I push to it.

Problem with this setup is it's multisite environment, so for updates requiring DB changes I should first put all sites offline one by one, then run update one by one, then verify that everything works. As number of sites grows this becomes very annoying procedure. Also this quickly becomes not an option because downtime grows for all sites in the group.
In an ideal world I would like to be able to deploy my code as "new platform", then "migrate" sites one by one to it - that is putting offline, moving web root to the new platform directory, running updates, verifying everything works and rolling back if it doesn't. Note that while I migrate single site, other sites should continue working on old platform, so if something breaks during deployment, the problem is isolated in single site.

For the moment you can build a duplicate platform on the production server and migrate

Does it look like the stuff I decribed above ?

, but the intention is for aegir to be able to deal with deployment, and work is already underway for that.

How would that work compared to the above ?

Get on #aegir on irc.freenode.net if you want to talk about this some more.

This is very interesting. One small problem is I'm don't like IRC much as I think it's timesucker. But I will probably have to deal with it one way or another.

yes.

adrinux's picture

Well, your setup sounds pretty much like a vendor branch style approach, but in git.
Yes, it looks like what you describe. Aegir will migrate between platforms as you describe, rollback if an error occurs etc

How would that work compared to the above?

RIght now, as long as you do everything on one server it'd work pretty much as you describe. You keep your patches and custom code in a git repo/repos, use drush_make to assemble platforms including those and use aegir to migrate your sites between platforms.

Right now aegir can't deploy from one server to another – there are workarounds, such as running aegir's backup task on a site transferring the backup.tgz and then importing on the other server, or just copying over your build file to production and building a duplicate platform.

But there is currently work in progress to make that possible. Eventually you should be able to migrate a site to a different server. Is that clearer?

Yes it is. Thank you for the

crea's picture

Yes it is. Thank you for the explanation. I'll definitely try Aegir and drush_make.

Aegir hosting system

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: