community.aegirproject.org

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:
Repo

• live.site.com
  
• staging.site.com
  
• dev.site.com
  
• branchx.site.com
  

But here is how it should look on Aegir:
Aegir
- platform: live
-- live.site.com
-- staging.site.com

• platform: dev
  -- dev.site.com
  

• platform: external dev server
  -- branchx.site.com
  

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 http://svn.site.com/our-repo/dev.site.com ~/platforms/dev/sites/dev.site.com

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,

Regards
Adrien