Direkt zum Inhalt

Ein Drupal Workflow mit Continuous Integration: Teil 1

16.12.2011 - 13:21 von Gast

Viele Drupal-Entwickler und Entwicklerteams kennen sicher das Problem: Man arbeitet mit mehreren Personen gemeinsam im Team, und die einzelnen Workstations haben einfach nicht den gleichen Entwicklungsstand, da jeder so ein bisschen andere Daten und Einstellungen in "seinem" Drupal hat. Ein anderes Problem ist es, eine bestehende Webseite mit viel wechselndem Content updaten zu müssen, ohne das der manuelle Deployment-Aufwand überhand nimmt. Jetzt schreien sicherlich viele "Aber dafür gibt es doch Features und Drush, und XYZ", und das ist auch korrekt. Aber auch damit ist nicht immer alles ohne Probleme möglich, und Drush ist auch nicht überall einsetzbar.

In unserem Team haben wir daher einen kompletten Drupal-Workflow entwickelt, der viele Probleme des Deployments abdeckt, gleichzeitig eine höhere Transparenz für den Kunden bietet, sowie die allgemeine Qualität erhöht.

Heute werde ich auf die Basis dieses Workflow eingehen, ohne zu sehr ins Detail zu gehen. Worauf stützt er sich, was sind die Tools, die wir benutzen?

Die Stützpfeiler des Workflow

  • Code Versionierung mit GIT
  • Continuous Integration mit Jenkins
  • Dev - Stage - Live Server
  • Der Updatescript-Prozessor




 

GIT als Revisionssystem

Wir benutzen GIT als Sourcecode Repository. Es ist sehr flexibel und deutlich besser als "ältere Systeme". Durch seine dezentrale Arbeitsweise ist man nicht auf Konnektivität zum "zentralen" Repo angewiesen, es arbeitet sehr schnell (auch auf Windows) und dadurch zögert man auch nicht, mal schnell einen branch zu erstellen und etwas auszuprobieren. Der Rest des Teams ist davon unbeeinflusst und muss nicht um seinen Code bangen. Es gibt für jedes Projekt ein zentrales Bare-Repository, in das die Entwickler pushen. Hieraus werden auch die einzelnen Instanzen gebaut. Doch dazu gleich mehr...

Continuous Integration, Jenkins

CI ist eine angenehme Geschichte. Es bedeutet in unserem Fall, das es einen "Dev"-Server für jedes Proiekt gibt. Alle Git-pushs in das zentrale "Bare" Repository werden auf diesen Dev-Server ausgecheckt. Das macht Jenkins für uns. Jenkins ist eine mächtige Verwaltungsoberfläche für genau diese Aufgabe. Jenkins hat für jedes Projekt mehrere Build-Jobs. Für den Dev-Server schaut Jenkins alle paar Minuten, ob neue Commits in das Repository eingegangen sind. Falls ja, checkt er diese auf den Dev-Server aus, und führt anschliessend noch ein paar Aktionen aus (z.B. Updatescripts ausführen). Somit hat der Dev-Server immer den aktuellen Arbeitsstand des Teams. Das hat den entscheidenden Vorteil, das jeder Entwickler immer direkt sehen kann, wie sich sein Code mit dem Code der anderen verträgt. Sollte etwas schief laufen, sehen es gleich alle und der Fehler kann schnell behoben werden. Jenkins kann auch Phpunit oder Simpletests ausführen. Wenn diese fehlschlagen bekommen die Entwickler eine Email, die darauf hinweist. Jenkins hat noch weitere Buildjobs, zum erstellen des Stage-Servers und zum updaten der Liveseite. Dies wird dann allerdings immer manuell ausgeführt.

Dev, Stage, Live

Wie schon im vorigen Absatz beschrieben, ist der aktuelle Entwicklungsstand immer auf dem Dev-Server vorhanden. Dieser Stand ist nicht immer "stabil". Er stellt auch einen dedizierten Dev-Branch im Repository dar.
Der Master-Branch des Repositorys ist für stabile Versionen, welche auch auf den Live-Server gestellt werden. Wenn also der Entwicklungsvorgang abgeschlossen ist, wird der Entwicklungsstand zuerst auf den Stage-Server deployed. Hier kann begutachtet werden, wie die Codeänderungen mit den aktuellen Livedaten zusammenspielen. Der Kunde kann sich diesen Stand ansehen, und sein finales Go für den Livegang geben. Dann wird der Stand getaggt, in den Master-Branch gemerget, und von dort wiederum via Jenkins auf den Liveserver gespielt. Da hier keine manuellen Vorgänge mehr stattfinden, sind die eigentlichen Deployment-Vorgänge sehr fehlerresistent und schnell. Das minimiert auch die Downtime einer Webseite.

Updatescript Processor

Um reibungslose und komplett Codegesteuerte Abläuf zu ermöglichen, hat unser Entwicklerteam einige Drupal-Hilfsmodule entworfen. Wir benutzen zum Deployment die üblichen Hilfsmittel wie z.B. Features. Aber manchmal sind dessen Möglichkeiten nicht ausreichend, oftmals muss eine Systemeinstellung gesetzt werden, die nicht mit features exportierbar ist, oder es muss (einmalig) ein Node erstellt werden... etc...
Hierfür gibt es den Updatescript Processor. Er ermöglicht es mit kleinen Scripts, die innerhalb des sites/all/updatescripts Ordners liegen, Drupal Code auszuführen. Dadurch lassen sich zum Beispiel Module aktivieren und deaktivieren, Systemeinstellungen vornehmen, Datenbanktabelleneinträge importieren oder Nodes erstellen, sowie bestimmte features reverten. Dies glieder sich alles in den Workflow ein. Wenn ein Entwickler zum Beispiel ein Modul entwickelt hat, stellt er einfach ein Updatescript zur aktivierung dieses Moduls zur Verfügung und checkt beides in das Repository ein. Seine Kollegen erhalten beim nächsten Pull somit automatisch alles was für dieses Modul benötigt wird. Sie müssen nur die Updatescripts ausführen, und sind somit ready to go. Auch Jenkins führt beim updaten des Dev-Servers immer automatisch die Updatescripts aus. Somit ist der Dev-Server immer automatisch auf dem aktuellsten Stand, was Konfiguration der Webseite betrifft. Zu guter letzt führen die Updatescripts dazu, das sie - am Ende der Entwickllungs - auf dem Live-Server einmalig ausgeführt werden, und damit alle Systemeinstellungen gesetzt werden, ohne das nochmal jemand Hand anlegen muss.

Es gibt also einen komplett sauberen Build-Prozess, wie es in der Softwareentwicklung vorausgesetzt werden sollte. Das bildet die Basis für hochwertige Softwareprojekte mit Drupal. Dank Jenkins hat der PM jederzeit Einblick in den aktuellen Status der Tests, sieht die Auswertungen der Softwaremetriken (Copy Paste Detection, LOC, Tests). Sollten Probleme entstehen, wird der Build-Prozess abgebrochen. Probleme wie "Das kann aber nicht mit Features exportiert werden" sind damit endlich Vergangenheit.

Ich hoffe ich konnte einen kleinen Einblick in unseren Workflow geben, der die Vorteile dieses Systems schmackhaft macht. Es werden noch weitere Artikel zu den einzelnen Punkten folgen. Das Updatescript-Prozesser Modul befindet sich derzeit noch in Entwicklung. Sobald eine ausgereifte Version zur Verfügung steht, werden wir diese auch der Community zugängig machen.

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

Weitere Blogbeiträge