Direkt zum Inhalt

Drupal Deployment

17.06.2013 - 08:03 von Manuel Pistner

Deployment ist oft kein Zuckerschlecken. Denn ohne konkrete Strategien, endet es meist im Chaos und im schlimmsten Fall sogar in einer unauslieferbaren Software.

Nachschlage-Werke

Einige hilfreiche Blog-Artikel zum Thema haben wir auf brightsolutions.de bereits veröffentlicht. Nachfolgend zähle ich die Links zu diesen Artikeln daher noch einmal auf und gehe danach auf ein paar häufige Probleme und Fehler rund um das Deployment von Drupal-Software ein.

Diese Links sollen euch als Nachschlagewerke dienen, um die Beschreibungen in diesem Blog-Artikel besser nachvollziehen zu können.

Die Schwierigkeiten des Deployments

Jeder, der schon einmal Web-Software für einen Kunden oder eine eigene Publikation entwickelt hat, stand vor dem Haupt-Problem des Deployments, welches ich mit einer rhetorischen Frage beschreibe: „Wie kann ich nach Änderungen an meinem lokalen System, die Software auf den Kunden-Server/meinen Server bringen ohne dabei etwas kaputt zu machen?“.

Ohne Frage, ist dies eine Schwierigkeit. Denn damit beschäftigen sich Unternehmen immer wieder und Google liefert zu „cms deployment“ über 7 Millionen Treffer.

Nicht für jede Software, auf CMS Basis kann die selbe Antwort auf die oben gestellte rhetorische Frage gegeben werden. Denn die Antwort hängt stark von den Möglichkeiten des jeweiligen CMS ab.
Für Drupal-Software, kann ich Ihnen jedoch ein paar hilfreiche Antworten liefern.

Da zuverlässige Deployment-Prozesse guter Strategien und strikt beachteter Anforderungen an die Art wie die jeweilige Software zu entwickeln ist, bedürfen, werden die Antworten nachfolgend ausführlich dargestellt.

Datenbanken hin und her kopieren

Dazu möchte Ich ihnen lieber keinen Tipp geben, aber anmerken, dass Deployment nicht derart auszurichten ist.

Jedes Mal, wenn Sie zum Beispiel ihre Entwicklungs-Datenbank auf die Live-Datenbank kopieren, laufen Sie Gefahr, dem Kunden bereits etablierte Änderungen am Content oder an Konfigurationen zu löschen.

Alternativen zeige ich weiter unten auf.

Content-Deployment

Es gibt in den meisten Fällen keinen vernünftigen Grund, weshalb Content automatisiert mit den Features deployed werden sollte.
In der Regel wird Content auf dem Live-System durch den Kunden, oder initial durch ein Mitglied des Entwickler-Teams eingepflegt.
Für initiales Einpflegen von Content, kann dies zunächst auf einer Stage-Installation durchgeführt werden, von wo aus die komplette Installation samt Datenbank-Inhalten auf den Live gespielt werden kann. Allerdings ist das wirklich nur dann zu empfehlen, wenn es sich um den ersten Live-Gang der Software handelt.

Ansonsten sind Content und Features beim Deployment zu trennen, wobei das Deployment sich nur auf die Features beziehen sollte.

Sie können sich jedoch eine Installation für Redakteure anlegen, welche 1:1 den selben Stand besitzt, wie die Live-Installation.
Dort können die Redakteuere Content einpflegen und vom Kunden abnehmen lassen, wonach Sie den jeweiligen Content, dann einfach per Copy/Paste ins Live-System übernehmen können.

Feature driven Development

Features werden im Sinne von Bündeln von Komponenten-Konfigurationen (Views, Content-Typen, Vokabulare, etc. ...) und gegebenenfalls angepasster Business-Logik meist mithilfe des „Features“ Moduls generiert.

Siehe hierzu den Blog-Artikel an Aufzählung 6 unter "Nachschlage-Werke".

Es ist die beste und einfachste Art Features auslieferbar zu machen.
Der Grund hierfür liegt in der Tatsache, dass Feature-Module einer Versionierung unterliegen und jeweils einen kompletten, abgeschlossenen funktionalen Aspekt abdecken, der komplett deployed werden kann. Zum Beispiel wäre ein Gästebuch, welches aus einem Gästebuch-Eintrag Content-Typen und einer View zur Anzeige der Einträge besteht, per Aspekt-Logik ein Feature.

Da Features ja, wie gesagt, Module sind, lassen sich auch Aktualisierungs-Routinen in ihrem Install-Entrypoints (.install Dateien) über hook_update_N Implementationen integrieren.

Zudem können Features Abhängigkeiten zu anderen Modulen besitzen.

Wer beim Entwickeln also feature-orientiert denkt und handelt, ist zumindest auf der sicheren Seite im Deployment-Prozess, da Features komplett deployed und dabei auch Änderungen in den Abhängigkeiten berücksichtigt werden können.

Häufigste Fehler beim Featuring

Features sind dann nicht konsistent deploybar, wenn Content ins Spiel kommt.

Hin und wieder haben Entwickler die Idee, Content, zu welchem auch Vokabular-Terme zählen in Features zu packen. Da Content aber in Drupal 7 mit serialisierten IDs in der Datenbank verwaltet wird, kommt es zu massiven Problemen beim Deploying von Features auf das Live-System eines Kunden, wenn dort zuvor schon Content gepflegt wurde.

Terme und Nodes besitzen dann im Feature bereits die Datenbank-IDs des Quellsystems, wobei die Autoincreement-Counter der Inhalte auf den Zielsystemen schon einen höheren Wert haben und anderer Inhalt mit den selben IDs auf den Zielsystemem schon existieren.

Generell sind von diesem Problem auch alle Konfigurationen betroffen, welche in der Datenbank mittels serialisierter ID verwaltet werden.
Daher auch hier nochmal der Hinweis, dass Inhalt und Konfiguration beim Deployment zu trennen sind.

Was ist ein Feature genau?

  • Ein Feature ist ein Drupal-Modul, das eine Sammlung von Drupal- Entitytypen für ein oder mehrere bestimmte Use-Cases enthält, welche sich funktional aneinander anlehnen.
  • Ein Feature-Modul enthält Konfigurationen anderer Module, welche als Komponenten angesehen werden. (Views, Content-Typen, Blöcke, Rollen, etc...)
  • Ein Feature behandelt keinen generellen Problem- Bereich (ist kein generisches Modul, sondern löst eine konkrete und spezifische Aufgabe.)
  • Ein Feature ist kein Installations-Profil.

Continous Integration bei uns

Zum Schluss möchte euch noch ein paar Einzelheiten zu Continous Integration bei uns im Hause vorstellen.

Wir entwickeln unser CI-System heute ständig bei Bedarf weiter, obschon wir uns dazu auch in der Vergangenheit schon sehr viele Gedanken gemacht haben.

Was wir derweil erreicht haben, ermöglicht uns saubere und nicht komplexe Deployments unserer Kunden-Projekte.

Das nachfolgend beschriebene Modell unseres CI-System wird Ihnen die wichtigsten Elemente dessen zeigen.

Deployment-Prozess Modell

GIT für Kolaboration

Unsere Projekte liegen in separaten GIT-Repositories, welche von einem Jenkins(siehe weiter unten) genutzt werden, um die Software auf den Stages zu bauen.

Entwickeln auf lokaler Dev-Installation

Alle unsere Entwickler arbeiten jeweils lokal auf eigenen Projekt-Installationen, welche initial aus dem jeweiligen GIT-Repository geklont werden.
Commits werden dabei Task basierend abgesetzt und gepusht wird nur was lokal erfolgreich gestetet wurde.
Der Push richtet sich dabei zu einem Development-Branch.

Building

Das Building des aktuellen Software-Standes wird über Jenkins durchgeführt. Jenkins ist eine zentrale Software, mit deren Hilfe ein sogenannter Build durchgeführt werden kann. Dabei bezieht die Software den aktuellen Stand aus dem Dev-Branch, lässt automatisierte Tests durchführen, erhebt Software-Metriken und prüft auf die Einhaltung von Coding-Standards.

Beim Building werden auf einer Ziel-Installation die Änderungen aus dem Repository eingespielt. Die Features werden dabei angewiesen zu „reverten“, also ihren aktuellen Zustand im System zu etablieren und es werden sogenannte Updatescripts gestartet.

Wir verwenden diese Updatescripts, um Basis-Konfigurationen auf den jeweiligen Installationen zu etablieren (Siehe: http://drupal.org/project/updatescripts). Mit einem Dev-Build erzeugt Jenkins eine Aktualisierung einer Development-Installation, welche auf seinem Server in einem Web-Verzeichnis liegt und über Apache2 zugreifbar ist.
Auf dem Dev-Server können die aktuellen Stände der Features im Repository händisch getestet werden. Zum Beispiel für einem Staging-Abnahme.

Mit einem Stage-Build erzeugt Jenkins eine Aktualisierung der Stage-Installation, welche ebenfalls auf seinem Server in einem Web-Verzeichnis liegt und über Apache2 zugreifbar ist.
Auf dem Stage-Server können Kunden oder interne Product-Owner den aktuellen Stand abnehmen und zu etwaigen Problemen und Unstimmigkeiten Tickets in unserem Intranet anlegen. Der Stage-Build kann zu einem Release-Candidate werden, wenn alles stimmig und fehlerfrei ist. Der Release-Candidate ist also ein potentieller Kandidat für das Deployment der fertigen Features (z.B. eines Milestones) auf das Live-System des Kunden.

Bei offenen Fragen oder Vorschlägen für weiterführende Blog-Artikel freue ich mich jederzeit über eine Kontakt-Aufnahme.

Liebe Grüße
Marc Sven Kleinböhl

Registrieren Sie sich jetzt für unseren kostenlosen Newsletter und bleiben Sie immer auf dem Laufenden

Weitere Blogbeiträge