Ralf Hendel, Geschäftsführer
Drupal Enthusiast und Freizeit-Pianist.

Drupal deployment

Deployment standortgebundener Einstellungen in Drupal

Mit Methoden wie git, Features und Drush sql-sync bzw. Drush rsync lassen sich Konfigurationen lokal entwickeln und anschließend einigermaßen komfortabel gegen Produktivsysteme ausrollen.

Dennoch benötigen die Umgebungen, auf denen entwickelt wird, an einigen Stellen unterschiedliche Einstellungen als die Live-Sites, auf denen die Seiten produktiv laufen.

Mit Methoden wie git, Features und Drush sql-sync bzw. Drush rsync lassen sich Konfigurationen lokal entwickeln und anschließend einigermaßen komfortabel gegen Produktivsysteme ausrollen.

Dennoch benötigen die Umgebungen, auf denen entwickelt wird, an einigen Stellen unterschiedliche Einstellungen als die Live-Sites, auf denen die Seiten produktiv laufen.

Hilfe, wo bin ich? Der "Environment Indicator" schafft Orientierung.

Nichts passiert schneller, als irgendwelche Einstellungen versehentlich auf einer Live-Site anstatt der lokalen stage zu konfigurieren. Es liegt ja in der Natur der Sache, dass die beiden Seiten absolut gleich aussehen.

Ein sehr praktisches Modul, das die unterschiedlichen Umgebungen visualisiert, ist der "Environment Indicator". Das Modul ist extrem simpel und stellt auf den Websites einen schmalen farbigen Balken mit einem Text dar, der hilft, die Orientierung zu behalten.

Die Environment-Indicator Einstellungen für Text und Farbe finden sich unter /admin/config/development/environment_indicator.

Üblicherweise verwenden wir rot für Live-Sites, orange für Abnahme-Stages und grün für lokale Umgebungen. Als Text nehmen wir etwas in der Art wie "[Projektname] - Livesite".

Einstellungen standortgebunden hinterlegen

Hier fängt das Problem aber schon an: sobald man die Datenbank der Livesite in die lokale Umgebung kopiert, werden die Umgebungs-Einstellungen mit übertragen, die bei Drupal in der Datenbank gespeichert liegen. Plötzlich werden alle Umgebungen zu "Live-Sites", auch die lokalen.

Bei diesen standortgebundenen Einstellungen kommt es also darauf an, sie so abzulegen, dass sie nicht mit der Datenbank übertragen werden bzw. sie diese übersteuern.

Eine Möglichkeit dafür bietet die settings.php. Es reicht vollkommen aus, diese Variablen irgendwo in der settings.php zu speichern, damit sie beim Aufruf von Drupal die Werte aus der Datenbank überlagern:

$conf['environment_indicator_text'] = 'MY PROJECT LOCAL';
$conf['environment_indicator_color'] = 'green';

Um sicher zu gehen, dass diese Werte nicht potentiell später durch andere inkludierte Code-Fragmente übersteuert werden, ist es ratsam, sie ganz am Ende einzufügen.

Unterschiedliche Versionen von "settings.php" in einem Projekt

Das Ganze wäre natürlich vollkommen vergeblich, wenn die settings.php von der git Quellcode-Versionsverwaltung mit überwacht und ausgerollt wird.

Die Freistil-Box Architektur bietet hierfür die sehr hilfreiche Voraussetzungen: für jede Umgebung lässt sich ein Label definieren wie z.B. "production" oder "staging".

Beim git-push wird für eine entsprechende Datei "settings.production.php" auf dem Zielsystem ein Symlink "settings.php" erstellt, sodass dieses Datei auf der Umgebung für das Drupal dann "ganz normal" zur Verfügung steht.

Hierfür muss die lokale settings.php allerdings per .gitignore aus der Quellcode-Verwaltung ausgeschlossen werden. Unter /sites/default bzw. den entsprechenden Multisite-Verzeichnissen befinden sich neben der "normalen" settings.php dann für jede Freistil-Box entsprechend weitere settings-Dateien, die wie gewohnt in das git eingecheckt werden.

Die .gitignore, wie wir sie bei comm-press in der Regel verwenden, sieht so aus:

# Ignore .htaccess because of drupalconcepts deployment process and different settings of Live-Site and Stage
.htaccess

# Ignore configuration files that may contain sensitive information.
sites/*/settings.php

# Ignore paths that contain user-generated content.
sites/*/files
sites/*/private

# Exclude anything in the dev path.
/sites/*/modules/dev/
/sites/all/libraries/FirePHPCore/

#sass cache
/sites/all/themes/*/compass/.sass-cache/

// We won't need those files.
*README.txt
*CHANGELOG.txt
*COPYRIGHT.txt
*INSTALL.*txt
*LICENSE.*txt
*MAINTAINERS.txt
*STATUS.*txt
*UPGRADE.txt
web.config

# meld backup files.
*.orig*
/nbproject/

.DS_Store
*/.DS_Store

Systemwarnungen auf Live-Seiten unterdrücken.

Auf Live-Sites wird empfohlen, Systemwarnungen zu unterdrücken. Für die lokale Entwicklung sind diese Hinweise natürlich unerlässlich.

Die Einstellungen für die Ausgabe finden sich unter "Protokollierung und Fehler" - bzw. unter /admin/config/development/logging.

Hierbei stehen drei Optionen zur Auswahl:

  • value="0": Keine (für Produktiv-Sites empfohlen.)
  • value="1": Fehler und Warnungen
  • value="2": Alle Nachrichten (lokal und Stages)

Ein Einzeiler in der settings.php regelt das für Live-Sites:

$conf['error_level'] = 0;

Bzw. für lokale Umgebungen:

$conf['error_level'] = 2;

Datensicherung mit "Backup and Migrate"

Ein phantastisches Modul für Backups ist "Backup and Migrate".

Auf Livesites wird man die Datenbank sicherlich häufiger sichern wollen als auf lokalen Umgebungen oder Abnahme-Stages, sofern man die überhaupt sichern will. Außerdem wäre es praktisch, wenn der Datenbankname unterschiedlich wäre.

Als Name der Sicherung würde man möglicherweise ein Schema der Art [sitename]-livesite+Zeitstempel verwenden.

Obwohl es zu dem Thema Issues aus dem Februar 2009 gibt, sind die Einstellungen aus Backup and Migrate nicht exportierbar. Siehe hierzu "Add option to store backup profiles in code" bzw. "Make backup profiles and schedules Features exportable".

Inzwischen lassen sich in Features zwar die drei Strongarm-Variablen "backup_migrate_destination_id", "backup_migrate_profile_id" und "backup_migrate_source_id" exportieren. Im Feature befinden sich dann aber nur quasi-leere Einträge und nicht die Konfigurationen in Form dreier Arrays.

Tja - mit Drupal 8 wird alles besser...

Ich wäre glücklich, wenn sich auch in Drupal 7 noch mal jemand dieses Problems annehmen würde. Aber ich bin leider kein Entwickler. :-(

Wenn Ihr noch Ergänzungen oder Anregungen zu diesem Thema habt, freue ich mich über Euer Feedback!

Kommentare

Ralf Hendel - 29. Januar 2013 - 15:22
<p>Hallo d13n,</p><p>das lag am Markdown-Filter, der Sternchen in kursive Auszeichnung übersetzt hat. Ich habe es eben korrigiert.</p><p>Danke für Deinen Hinweis!</p>
d13n - 29. Januar 2013 - 12:49
Es fehlen jeweils die Sterne (*) zwischen den Slashes, also z.B.: sites/*/settings.php, statt sites//settings.php. Aha! Ihr entwickelt also mit Netbeans ;-) (/nbproject/) Der Environment Indicator ist bei mir allerdings schon manchmal mit anderen Overlays kollidiert, wie z.B. UserVoice. Ich mache mir meistens noch filestamps ins Haupverzeichnis (__LIVE, __STAGING, __DEVEL), die dann natürlich auch in die .gitignore müssen. Dadurch sehe ich dann gleich auch von der Shell aus, wo ich gerade bin. Damit lass ich dann auch noch über die page.tpl eine Warnmeldung anzeigen, wenn ich nicht auf der LIVE-Site bin. Aber der Tip von webcultist ist genial!
webcultist - 29. Januar 2013 - 10:37
...fügen wir gerne noch folgendes in die Settings.php bzw. in eine darin inkludierte custom.settings.php ein: $conf['cache'] = FALSE; // Page cache $conf['block_cache'] = FALSE; // Block cache $conf['preprocess_css'] = FALSE; // Optimize CSS files for Livereload $conf['preprocess_js'] = FALSE;// Optimize JavaScript files