Managing your code in the Aegir Style

Aegir “enforces” some good practices, but not to make your work fancy in the “Aegir Style”, rather to make it secure, effective and re-usable (modular). For example, it manages some secure permissions to save you headaches later, when you will try to really use the full Aegir power to migrate, clone, batch upgrade many sites etc. It also fails and reverts any changes if any task causes errors, so you can debug your sites issues and try again until it works without any issues.

Of course Aegir doesn’t help you in maintaining modules installation and upgrades, but it allows you to migrate Sites between Platforms, so you have to create a new Platform with new modules versions and then migrate the Site, when you wish to upgrade it securely, with automatic and instant roll-back, if anything goes wrong in the process. It is always recommended to clone the Site in the existing Platform and test migration of the cloned Site first, before trying it with your live Site. You may want to read a few very useful, related articles:

Your Drupal Site Upgrade — Safe Workflow »
Import your sites to Aegir in 8 easy steps »
How to add custom platform properly? »
The best recipes for disaster – a must read »
Are there any specific good habits to learn? »
Migrate sites between installation profiles »

To better understand the logic behind Aegir and associated tools, it helps when you start thinking that the Site is not an App, it is the Installation Profile which is an App, and the Site is only this App’s provisioned instance, while the Makefile is the easiest way to define and create a Platform, and the Platform is an environment where your Apps (the installation profiles) live.

The recommended (and also more advanced) way to manage your Sites code is to use Makefiles (and then Drush Make) to build your Platforms, apply patches to contrib or custom modules etc, then using Profiler module to create your custom Installation Profile and manage in your Git repo just your Makefiles, your Installation Profiles and only your custom modules and patches – in a separate repo per module and per theme.

Note that you could have more than one Installation Profile per Platform, so there is no need to multiply Platforms, when they share most of the code, just differently configured/used.

Working that way you will be able to easily re-use your work, to create new Installation Profiles, Platforms, and avoid duplication.

A must-read articles by Bill Powell on cms.about.com

What Is a Drupal Distribution? »
What Is a Drupal Installation Profile? »
Aegir Platforms: A New Model for Thinking About Drupal Web Sites »
What Is a “Platform” on Aegir? »
How to Organize Your Modules Into an Aegir Drupal Platform »
Choose Drupal Modules Wisely »
How Aegir “Upgrades” Your Drupal Site By Migrating Between Platforms »
Never Upgrade Drupal Modules. Instead, Make New Aegir Platforms. »
Website Changes Should Be Tested on a Copy »

Recommended, related presentation by Matt Petrowsky:

Other recommended, related articles:

Core Conceptions »
Automating Drupal Development: Makefiles, Features and beyond »
Building and Maintaining a Distribution in Drupal 7 with Features »
Drush Make – Drupal Distributions Packaging Automation Tool »
Drush Make theory for happy profile development »
Aegir hosting system »