This site is a static archive of the Aegir community site. Documentation has moved to Other community resources can be found on the Contacting the community page.
Skip navigation

SVN (or any version-control) friend with Aegir


SVN (or any version-control) friend with Aegir

Hi Everyone,

I’m about to build a module that would make Ægir friendly with SVN or any version-control system. It would set up all configurations automatically when creating or migrating a site on Ægir.

I’ve been digging around for a while now to find a way to easily make Ægir work with SVN (Or whatever version control system) and having an easy dev/staging/live workflow. I had to change my workflow process but now all is working pretty much just like I wanted. Only issue, it requires some manual configurations when migrating websites from one platform to another one. That’s why I’m about to build a module that would do it all automatically. But before that, I’d like to see if someone has some advices, sees a potential issue or did something similar already.

I’m aware of these interesting posts (You, Drupal and Version Control, Drupal deployments & workflows with version control, drush_make, and Aegir, Drupal Release Management with Drush and Git, and etc etc.) but I must say I disagree a bit with mig5 on the workflow he’s proposing. (may be I got it wrong). This is how I make my workflow work:

The dev/staging/live sites can only be standard (multi)sites for Ægir, and in the meanwhile they should all be in the same version-control repository to ease the merging, tag branch etc processes. I think it’s also cleaner to have all project related sites or files into one same repository.

This is how the repo looks like:

But here is how it should look on Aegir:
- platform: live
- platform: dev
- platform: external dev server

This last tree makes impossible to do a standard full checkout of the repo as almost each site uses a different path. But this is easily solved; by making each Aegir site a partial checkout of the repo
ie: $ svn checkout ~/platforms/dev/sites/

This combined to an auto-checkout script launched on post-commit event, works just great. The only issue is for each site’s auto-checkout path, as they need to be defined in the script. This means that every time I want to migrate an Aegir site to another platform, I need to manually update the repo auto-checkout paths, which means a non shell user cannot migrate sites. This is why I want to develop this module, that would update the auto-checkout paths, but also let them configure all the repo users and repo configurations directly through the UI, allowing a non shell user to customise the version-control configurations.

An advantage of the methods described above (and it’s mostly shared by mig5’s post) is that we no longer track the drupal core code, neither the contributed modules; only the site’s related files (excluding setting.php, drushrc.php and files/). To update a site, we update its platform’s code. To do so and be able to reverse to the old code, we just create a new platform (really easy with a makefile) and we then migrate the site to the updaded platform. We can this way migrate back to the old platform if needed.

To sum up what the module would do:
- Set allowed users to a repo on the version-control configurations
- Set the http dav access for the repo url
- Create Repository nodes which would create a real repository
- Create a repository node, but associating it to an existent real Repository
- Create a repository node and a Repository when creating a new site
- Associate a site to an existent Repo when creating the site
- Add/commit to an existent repository the site’s code when creating/associating a site
- Replace the Aegir site’s code by a partial checkout of the repository
- Exclude files modifiable by Aegir (setting.php, drushrc.php and files/)
- Set the auto-checkout path for each versioned site.
- Update the auto-checkout path on migration and deletion.
- etc

From this, would someone have comments or advices? More features in mind?



Thanks for sharing Adrien :) Here is a related post you might be interested in

Need help?


The discussion area lets your team communicate by posting updates and discussing issues. It is a great place for sharing progress, discussing challenges, and exploring ideas.