comm-press: Your Drupal agency in Hamburg, Germany: Consulting, training, programming, service, webdesign and hosting

Knowledge . Deployment in Drupal - ein Erfahrungsbericht

von Ralf Hendel
am

Wie ändere ich auf einer Live-Site zuverlässig Dinge an der Konfiguration ohne ihre Stabilität zu gefährden? Bei trafficstarken Produktivsites dürfen nur getestete Codes in das System übernommen werden und die Downtimes müssen so kurz wie möglich sein.

Wie kann ich das in Drupal erreichen? Im folgenden Beitrag möchte ich die Möglichkeiten und Herausforderungen von Drupal darstellen sowie die unentbehrlichen Tools und Helferlein rund um Drupal vorstellen, ohne die ein Arbeiten mit Drupal gar nicht mehr möglich erscheint.

Staging

Um Änderungen in Ruhe durchführen und testen zu können empfiehlt es sich zuallererst, die Live-Umgebung in eine separate zweite Entwicklungsumgebung zu klonen. Dort können die Änderungen vorgenommen und getestet werden.

In der kleinsten Version bestehen zwei Sites nebeneinander. Dieses System lässt sich für komplexere Anforderungen jedoch beliebig erweitern. Bei Arbeiten im Team ist es sinnvoll, lokale Stages zu betreiben und darauf zu entwickeln. Auf jedem Entwicklerrechner läuft ein Webserver mit vollständiger Umgebung. Lokal getestete Arbeiten werden nach Abschluss in eine zentrale Umgebung übertragen, in der die Arbeiten des Teams zusammengeführt werden.

Diese Umgebung ist aber nicht zu jedem Zeitpunkt stabil bzw. im Produktivsystem einsetzbar, da dort auch teilfertige Arbeiten an Abschnitten ausgerollt werden können, die erst nach vollständigem Abschluss durch den Kunden nutzbar sind. So können dort z.B. Konfigurationsarbeiten oder neue Module vorhanden sein, deren Ausgabe aber noch nicht "gethemt", das heißt, gestaltet ist.

Zum Endtest durch Entwickler und Kunden ist es also sinnvoll zwischen der zentralen Umgebung und Produktiv-Site noch eine Abnahmeumgebung zwischen zu schalten, auf der sich nur stablile Releases befinden.

Projektmanagement und Vier-Augen Prinzip

Wir arbeiten in der Regel agil nach Srcum oder Kanban. Für jede Anforderung werden Userstorys und Tasks geschrieben, die als kleine Zettel mit Magneten an einer großen Wand mit einem Raster aus Zeilen und Spalten hängen.

Jedes Projekt besitzt seine eigenen "Lanes". Das sind horizontale Bahnen, in denen die Tickets ihre verschiedenen Stadien der Verpuppung durchlaufen, bis aus hässlichen Bugs schöne Schmetterlinge werden.

Der lange Weg der Tickets

Die insgesamt zu leistenden Arbeiten werden in verschiedene Bauabschnitte in Form von "Iterationen" oder "Sprints" eingeteilt und umgesetzt.

Dabei werden die unterschiedlichen Stadien durch vertikale Spalten am Board bestimmt.

  • Die Dinge, die insgesamt zu erledigen sind, landen in der "Icebox" ("bloß nicht vergessen")
  • oder dem "Backlog" ("kommt bald dran").
  • Die Tasks, die in der laufenden Iteration behandelt werden, kommen in die Spalte "To Do".
  • Tasks, an denen ein bestimmter Mitarbeiter arbeitet, befinden sich mit einem Magneten mit Namen oder Icon des Mitarbeiters darauf in der Spalte "Work in Progress". Zum Beendigung eines Task gehört der Rollout in die Entwicklungs-Stage und ein abschließender Selbsttest durch den Mitarbeiter.
  • Danach wartet der Task in der Spalte "Ready to Test".
  • Ab dort müssen sie von einem anderen Mitarbeiter getestet werden ("Test in Progress").
  • Nach bestandenem Test ruht sich das Ticket in der Spalte "Ready to Rollout" ein wenig aus, bis es jemand in das Abnahme- oder Produktivsystem ausrollt und dort anschließend auch noch einmal testet.

Breakeven bei Projekten ab 15 Personentagen

Das klingt unglaublich aufwändig, weil jedes noch so kleine Ticket jede dieser Phasen durchläuft. Aus unseren Erfahrungen ist aber schon bei Projekten von ca. 15 Personentagen ein Breakeven erreicht, wo dieses Verfahren Zeit spart.

Abgesehen davon schont es die Nerven der Mitarbeiter und Kunden. Nichts ist unbefriedigender als das zeitraubende und nervtötende Suchen von Fehlern auf einer Live-Site, bei der man das Gefühl hat, alles schon mehrfach repariert zu haben – und trotzdem treten immer die selben hartnäckigen Fehler auf.

Am Ende hat man das Gefühl bei seinen Arbeiten gleichzeitig mehr kaputt als heil zu machen. Das Projekt fühlt sich wackelig an und man verliert das Vertrauen... Spaß an der Arbeit fühlt sich anders an!

Die Repräsentation der Tasks durch einzelne Zettel verhindert übrigens auch, dass unterschiedliches Mitarbeiter konkurrierend an den selben Aufgaben arbeiten. Selbstverständlich funktioniert dieses System nur, wenn sich alle konsequent daran halten. Bei uns war das ein Lernprozess...

Quellcode-Versionsverwaltung mit Git

Zum gemeinsamen Arbeiten im Team gehört auch eine Quellcode-Versions Verwaltung. Nichts ist schlimmer, als wenn verschiedene Mitarbeiter an den selben Dateien entwickeln und sich gegenseitig ihre Lieblings-Codes löschen.

Hier hilft eine Versionsverwaltung, die Konflikte verhindert. Die bekanntesten Lösungen sind meines Erachtens "SVN" und "Git". "Git" ist eine dezentrale Versionsverwaltung, die auch dann noch funktioniert, wenn der "zentrale" Server mit dem Bare-Repository gerade einmal nicht erreichbar sein sollte.

Git wurde ursprünglich für die Entwicklung von Linux entwickelt. Anfang des Jahres ist Drupal mit seiner Entwicklung auf Git umgezogen und auch wir bei comm-press haben mit Git sehr gute Erfahrungen gemacht.

Git ist für das Dateien-Handling selbstverständlich komplizierter als ein FTP-Programm. Git ist aber auch für mich als Nicht-Entwickler durchaus verstehbar und bietet unglaublich Sicherheit. Mittlerweile kann ich erst dann sicher schlafen, wenn die Dateien im Git liegen ...

Konfigurations-Management: Deployment mit Features und Strongarm

So weit, so schön – Aber wie steht es denn nun mit dem Deployment in Drupal? Wie lassen sich "Dinge" in Drupal denn überhaupt gegen ein anderes System "ausrollen"?

In Drupal befinden sich Konfigurationseinstellungen und Content in einer gemeinsamen Datenbank.

Ab einer bestimmten Projektgröße verbietet sich sehr schnell das Spiegeln einer vollständigen Kundeninstallation samt Content, die nach Abschluss der Arbeiten wieder in die Produktiv-Site zurückgespiegelt wird.

  • Für den Kunden wäre dies mit einem Content-Freeze über die gesamte Dauer der Arbeiten verbunden. Bei diesem System könnte immer nur das Entwicklerteam ODER der Kunde an seiner Seite arbeiten.
  • Abgesehen davon kann die Produktiv-Site vertrauliche Informationen enthalten, die das Intranet eines Kunden nicht verlassen dürfen.
  • Und bei einem Datenvolumen von mehreren Gigabytes kann ein ständiges Hin- und Her-Kopieren nicht mehr das ultimative Mittel der Wahl sein.

Hier helfen Konzepte wie Features und Strongarm weiter, die Konfigurations-Einstellungen in Code verpacken können, der sich schlank und bequem zwischen verschiedenen Umgebungen transportieren lässt.

Die meisten gängigen und alle Module, die auf CTools aufsetzen, besitzen exportierbare Einstellungen. Inhaltstypen, Views und Panels lassen sich fast vollständig per Features exportieren.

Beim Übertragen von Konfigurationsbestandteilen mit Features muss auf dem Zielsystem Features installiert und aktiviert sein.
Sofern sich die Konfiguration im Zielsystem nicht ausschließlich im Code sondern auch in der Datenbank befindet, muss dem Zielsystem nach dem Ausrollen neuer Codes noch mitgeteilt werden, welcher Stand maßgeblich ist. In diesem Fall müssen die Features einmal zurück gesetzt werden ("revert"). In aller Regel funktioniert das gut. Manchmal ist ein wenig Vor- oder Nacharbeit notwendig. Insbesondere beim Löschen von Feldern aus Inhaltstypen sollten diese vorher von Hand über die Oberfläche des Zielsystems gelöscht werden bevor die Features ausgerollt werden.

unverzichtbar: die Drupal Shell

Hier hilft drush, die "Drupal Shell", weiter. Features besitzt eine ausgezeichnete Drush-Unterstützung. Ich kann meine Arbeiten lokal konfigurieren und mit dem Befehl "drush fu [Name des Features] -y && drush cc all && drush cron" mit einem einzigen Kommando ein Feature-Update veranlassen, den Drupal Cache löschen und anschließend noch den Cron anwerfen, der einen Selbsttest auf dem System ausführt.

Auf der Jagd nach dem goldenen Vlies

Einige Einstellungen müssen erst etwas mühsam in der Systemdatenbank identifiziert bevor sie sich als Strongarm Variablen exportieren lassen. Es ist nicht sinnvoll, sämtliche Strongarm-Variablen in ein Feature zu packen, da das System dadurch sehr schwerfällig werden würde. Nur die tatsächlich benutzten Variablen sollten deklariert werden.

Bei der Suche nach diesen Einstellungen können Tools wie "Drupal for Firebug" enorm weiter helfen.

Protokollieren tut Not

Für Dinge, die sich nicht per Features ausrollen lassen, sollte unbedingt ein Rollout-Protokoll angelegt werden, das sämtliche Einzelschritte enthält, die auf dem Zielsystem ausgeführt werden müssen.

Im Umgang mit Features und Strongarm ist etwas Erfahrung erforderlich, um seine individuellen Best-Practices zu entwickeln.

Es empfiehlt sich das Zielsystem während des Rollout-Vorgangs in den Wartungsmodus zu versetzen.

UUID und Drupal 8 - kein Unterschied zwischen Content und Konfiguration

Eine Unterscheidung von Content und Konfiguration ist nur auf den ersten Blick trivial. Als Beispiel können Blöcke einfach nur Content enthalten wie z.b. die Öffnungszeiten eines Ladengeschäfts. Ebensogut können sie einen Teaser zu einem Shop beherbergen, der ein wichtiges Navigationselement der Seite darstellt.

Nodes, Blöcke und Taxonomie-Begriffe lassen sich auf herkömmliche Weise nicht exportieren. Nodes und Terms besitzen normalerweise serielle Identifikatoren. Bei zwei parallel laufenden Systemen werden zwei gleiche Terms in der Regel nicht die selbe ID besitzen. Für Views, die eine bestimmte Term-ID als Argument benötigen, ist das fatal.

Hier helfen Konzepte wie "UUID" ("Universally Unique IDentifier") weiter, die die seriellen Identnummern durch eindeutige Zeichenketten ersetzen. Dieses Konzept ist noch recht neu und wird in Drupal 8 stark forciert werden.

Deployment als Säule von Drupal 8

In Drupal 8 wird das Deployment unter dem Oberbegriff "Configuration Management" eine der vier Schlüssel-Initiativen darstellen.
Der Projekt Manager für das Konfigurations-Management in Drupal 8 ist Greg Dunlap alias "heyrocker" von Nodeone, einer schwedischen Drupal Agentur, der in Brüssel eine sehr interessante Session zu Deployment in Drupal 8 gehalten hat: "Treat things as things" - Alles muss exportierbar sein.

Last but not least: Drupal Hosting

Drupal spezialisiertes Hosting zeichnet sich durch Unterstützung der Deployment-Prozesse aus. Auf dem Server sollte ein Git Bare-Repository mit laufen, dass nach jedem "push" die Daten automatisch weiter gegen die Website ausrollt.

Das sites/default/files-Verzeichnis sollte als Container für die beweglichen Inhalte der Kunden von Git ausgenommen sein.
Besonders optimal wird es, wenn sich verschiedenen Instanzen einer Websites mit einem gemeinsamen Git-Repository steuern lassen. So lassen sich die unterschiedlichen Versionsstände ("Branches") aus einem gemeinsamen Git gegen verschiedene Umgebungen ausrollen.

Ein Provider, der sich auf Drupal Hosting spezialisiert und innerhalb kürzester Zeit zum Hosting-Trendsetter der Community aufgeschwungen hat, ist DrupalConcept aus Freiburg.

Bis vor zwei Jahren haben wir all unsere selbst-gehosteten Kunden-Projekte auf gemieteten dedizierten und durch uns selbst administrierten Servern unter gebracht. Dann sind wir – zugegebenerweise mit gemischten Gefühlen – den Schritt gegangen und haben alle Projekte auf DrupalConcept-Server übertragen. Wer gibt schon sein Hosting gern aus der Hand?
Inzwischen freuen uns jeden Tag aufs Neue diesen Schritt gegangen zu sein.

In Kürze steht der Umzug der Mail-Infrastruktur auf geclusterte DrupalConcept-Server auf dem Programm. Diesmal ohne gemischte Gefühle...

Drupal optimiertes Hosting

Von DrupalConcept erhalten wir eine gemanagte Infrastruktur zur Verfügung gestellt, die – ohne dass wir es überhaupt bemerken – bereits auf geclusterten Maschinen läuft, die jederzeit weiter skalieren können.

Davon abgesehen leistet Jochen Lillich, der Kopf hinter DrupalConcept jederzeit freundlichen, kompetenten und vor allem auch proaktiven Support. Es macht Spaß mit ihm zu tun zu haben!

Um Dinge wie Datensicherung, Betriebssystemupdates und Monitoring müssen wir uns nicht mehr selbst kümmern.

DrupalConcept bietet uns die Möglichkeit, unseren Kunden 24/7 Support zu bieten, und wir können uns weiter auf das konzentrieren, was wir am besten können – der Entwicklung von Plattformen mit Drupal.