Drupal-Projekte in Git

In der Regel kann man eine Drupal-Site mit einem Projekt gleichsetzen, Projekte nutzen eine Versionsverwaltung, immer häufiger ist dies Git.

Je mehr ich Git nutze, je weniger nutze ich die Möglichkeiten der klassischen Drupal-Multisite-Funkionalität, dem Teilen von Drupal-Core und Contributed-Modules über viele Drupal-Sites hinweg.

Im folgenden möchte ich diese (Verzeichnis-)Struktur innerhalb des Git-Repositories beleuchten und in diesem Zusammenhang Ansätze von spezielleren Drush-Konfigurationsdateien zeigen, welche sich in Drupal-Projekten für mich etabliert haben, ein Teil hiervon ist Drupal-7 spezifisch.

example.com/
|-- drupal
|   `-- sites
|       |-- all
|       |   |-- modules
|       |   |   |- features
|       |   |   |- contrib
|       |   |   `- custom
|       |   `-- themes
|       |-- default
|       |   |-- default.settings.php
|       |   |-- files
|       |   |-- themes
|       |   `-- settings.php
|       |-- example.sites.php
|       `-- sites.php
|-- dumps
|   `-- 20120615-185144.sql
|-- etc
|   |-- apache2
|   |   `-- sites-available
|   |       `-- example.com
|   `-- drush
|       |--- aliases.drushrc.php    
|       |--- git.drushrc.php    
|       `--- example.drushrc.php    
|-- privatefiles
|   `-- IMG_6445.JPG  
`-- salt
    `-- salt.txt
  • drupal

    Die Drupal Code-Basis und DocumentRoot des Webservers.

  • dumps

    Hier liegen die Datenbankdumps

  • etc

    Projektrelevante Konfigurationsdateien, relativ zur Wurzel des Dateisystems.

  • privatefiles

    Dateien die über Drupal verwaltet werden, (Ziel beim Hochladen: Private Dateien).

  • salt

    Beinhaltet in der Datei salt.txt, den aus settings.php ausgelagerten Salt

Vorteile der All-In-One Lösung

  1. Leicht deploybar

    Durch ein git clone ist das Projekt schnell auf einem weiteren Server verfügbar und eingerichtet.

  2. Teamgeschwingkeit

    Durch eine Gemeinsame Codebasis müssen Entwickler bzw. Projektbeteiligte z.B. nicht erst Site und Drupal-Core zusammenbekommen oder Konfigurationsdateien wie eine Apache-Virtualhost erstellen. So sinken Hürden und sie finden schneller in das Projekt.

  3. Automatisierbar

    Angefangen von einfachen Shell-Skripten zur Automatisierung bis hin zur Continuous Integration und Build-Tools wie ANT, Maven, PHING, Capistrano usw. läßt sich neben den Änderungen an der eigentlichen Code-Basis auch die Konfigurationen einfach einbeziehen.

  4. Weniger fragil

    Im Gegensatz zu einer Multisite-Umgebung, können Drupal-Core und Contrib-Updates sich nur auf dieses Projekt auswirken.

  5. Dezentrales Backup

    ...als netter Nebeneffekt, wenn Git-Server, wie Github oder die SSH-basierten Gatekeeper Gitosis oder Gitolite zwischengeschaltet sind.

Nachteile

  1. Redundanz

    Haben sich zuvor noch n Sites einen Drupal-Core und diverse Contributed-Modules, wie Views oder Admin Menü etc geteilt, so werden Diese jetzt für jedes Repository einzeln benötigt.

  2. Festplattenbelegung

    Das macht ca. 22 MB für ein Drupal-7-Projekt, bwz. ca. 8,5 MB für ein Drupal-6-Projekt je Core zusätzlich im Repository, Contributed-Modules noch nicht mitgerechnet.

drupal/sites/default/settings.php

Drupals Konfigurationsdatei.

Wie in der Datei default.settings.php empfohlen, bezieht die Variable $drupal_hash_salt zur Verbesserung der Sicherheit ihren Inhalt über eine Datei die außerhalb DocumentRoot des Webservers liegt.

$drupal_hash_salt = file_get_contents('../salt/salt.txt');

Drush im Git-Repository konfigurieren

Im folgenden werden Drush-Einstellungen gesetzt, welche uns dann für jeden Drush-Aufruf innerhalb des Repositories zur Verfügung stehen.

/etc/drush/drushrc.php

Vorraussetzung hierfür ist eine Anpassung der Datei /etc/drush/drushrc.php auf den beteiligten Rechnern.

Mit dem folgendem Codeschnipsel bringen wir drush dazu, innerhalb des Repositories in etc/drush nach Konfigurationsdateien, wie Alias-Definitionen zu suchen und hinterlegen zudem explizit git.drushrc.php.

exec('git rev-parse --git-dir 2> /dev/null', $output);
if (!empty($output)) {
  $repo = $output[0];
  $options['config'] = $repo . '/../etc/drush/git.drushrc.php';
  $options['alias-path'] = $repo . '/../etc/drush';
}

etc/drush/git.drushrc.php

Durch die Angabe der Drupal-Root und der Site kann via Drush der Drupal-Bootstrap-Prozeß durchlaufen, dies macht die Spezifizierung über die entsprechenden Optionen überflüssig.

$options['l'] = 'default';
$options['r'] = '/path/to/example.com/drupal';

Die Spezifizierung der Drupal-Wurzel $options['r'] kann man ähnlich wie im obigen Bespiel ebenfalls aus der Kombination von "Git-Dir" und Drupal-Root angeben.

Drush-Kommandos wie sql-cli lassen sich jetzt direkt mit drush sql-cli ausführen.

etc/drush/example.aliases.drushrc.php

Projektspezifische Alias Gruppe (GROUPNAME.aliases.drushrc.php).

Vorweg zur Entwirrung:
Die Wahl des Dateinamens leitet sich aus dem Projektnamen (example.com) ohne TLD (com) ab und die Ähnlichkeit mit der von drush ausgelieferten Datei ist eher zufällig.

Durch dieses Schema lassen sich einfach kanonische Aliasnamen, wie z.B.:

  • $aliases['localhost']

    @example.localhost für die lokale Entwicklungs-Umgebung

  • $aliases['is-loesungen.de']

    @example.is-loesungen.de für die Stage-Site

  • $aliases['com']

    @example.com für die Live-Site

des Projektes abbilden.

etc/drush/aliases.drushrc.php

Git-spezifische Alias Defininition mit Kommando-spezifischen Einstellungen, hier für sql-dump für Aufrufe innerhalb des Repositories.

Bei einem Aufruf von drush @git sql-dump weiss drush wo und mit welchen Dateinamen der SQL-Dump dieses Drupal-Projekt abgelegt wird.

Weiterführendes