So implementieren Sie Continuous Deployment mit Drupal

The Guardian, eine der vertrauenswürdigsten Nachrichtenagenturen, verfolgte einen anderen Ansatz für ihre Mitgliedschafts- und Abonnement-Apps. Anstatt den Schwerpunkt auf langwierige Validierungen in Staging-Umgebungen zu legen, legt die Continuous-Deployment-Pipeline von The Guardian größeren Wert darauf, sicherzustellen, dass die neuen Builds in der Produktion wirklich funktionieren. Ihr Ziel war es, die Entwickler wissen zu lassen, dass ihr Code in der realen Welt erfolgreich ausgeführt wurde, anstatt nur grüne Testfälle in einer bereinigten und potenziell nicht repräsentativen Umgebung zu beobachten.

So reduzierte The Guardian den Umfang der vor der Bereitstellung durchgeführten Tests und erweiterte die Bereitstellungspipeline, die Feedback zu Tests enthielt, die auf der Produktionsseite durchgeführt wurden. Dies unterstreicht die Bedeutung einer schlanken Continuous-Deployment-Pipeline, die einer großen Organisation wie The Guardian geholfen hat, sich auf die Produktionsvalidierung anstelle einer großen Suite von Akzeptanztests zu konzentrieren. Solche Vorteile lassen sich auch in Drupal-basierten Projekten beobachten, bei denen Continuous Deployment es uns ermöglicht, Drupal-Webanwendungen schnell zu iterieren.

Lesen Sie mehr über die Implementierung von Continuous Integration und Continuous Delivery mit Drupal

Eine kurze Zeitleiste von Continuous Deployment

Agile Alliance hat erklärt, dass die Ursprünge von Continuous Deployment bis in die frühen 2000er Jahre zurückverfolgt werden können. Im Jahr 2002 erwähnte Kent Beck, der Schöpfer von Extreme Programming, Continuous Deployment in den frühen (unveröffentlichten) Diskussionen über die Anwendung von Lean-Ideen auf Software, wo nicht bereitgestellte Funktionen als Inventar betrachtet werden. Es dauerte jedoch mehrere Jahre, bis es verfeinert und kodifiziert wurde.

Später, in den Proceedings der Agile 2006 Conference, wurde der erste Artikel, der den Kern von Continuous Deployment beschreibt - The Deployment Production Line - ins Rampenlicht gerückt. Veröffentlicht von Jez Humble, Chris Read und Dan North, war es eine Kodifizierung der Praktiken zahlreicher ThoughtWorks UK-Teams.

Bis 2009 hatte sich die Praxis des Continuous Deployment gut etabliert, wie aus dem Artikel Continuous Deployment at IMVU von Timothy Fitz hervorgeht. Es ist nicht nur in agilen Prozessen von Vorteil, sondern seine großartigen Funktionen können auch für Methoden wie ein Lean Startup oder DevOps extrahiert werden.

Continuous Deployment im Fokus

Während sich Continuous Integration auf den Prozess des automatischen Erstellens und Testens Ihrer Software in regelmäßigen Abständen bezieht, ist Continuous Delivery der logische nächste Schritt, der sicherstellt, dass sich Ihr Code immer in einem Release-bereiten Zustand befindet. Der ultimative Höhepunkt dieses Prozesses ist Continuous Deployment.

Bei Continuous Deployment wird jede Änderung, die alle Phasen Ihrer Produktionspipeline durchläuft, für die Kunden freigegeben

Bei Continuous Deployment wird jede Änderung, die alle Phasen Ihrer Produktionspipeline durchläuft, ohne menschliches Zutun für die Kunden freigegeben, und nur ein fehlgeschlagener Test verhindert, dass eine neue Änderung in der Produktion bereitgestellt wird. Es ist eine spektakuläre Möglichkeit, die Feedbackschleife mit Ihren Kunden zu vergrößern und das Team zu entlasten, da es den sogenannten "Release-Tag" aus der Gleichung nimmt. Es ermöglicht den Entwicklern, sich auf die Erstellung von Software zu konzentrieren, und sie können sehen, wie ihre Arbeit Minuten, nachdem sie alle Anstrengungen darauf verwendet haben, live geht.

Warum sollten Sie Continuous Deployment in Betracht ziehen?

Continuous Deployment kommt sowohl dem internen Team, das es implementiert, als auch den Stakeholdern in Ihrem Unternehmen zugute.

Für das interne Team

• Anstatt ein wöchentliches oder monatliches Release durchzuführen, ermöglicht der Übergang zu funktionsgesteuerten Releases schnellere und feinkörnigere Upgrades und hilft bei der Fehlersuche und Regressionserkennung, indem jeweils nur eine Sache geändert wird.
• Indem Sie jeden Schritt des Prozesses automatisieren, machen Sie ihn selbstdokumentierend und wiederholbar.
• Indem Sie die Bereitstellung auf dem Server vollständig automatisieren, kann ein wiederholbarer Bereitstellungsprozess erstellt werden.
• Indem Sie den Release- und Bereitstellungsprozess automatisieren, können Sie die laufende Arbeit ständig auf den Staging- und QA-Servern freigeben und so die Sichtbarkeit des Entwicklungsstatus gewährleisten.

Der Übergang zu funktionsgesteuerten Releases ermöglicht schnellere und feinkörnigere Upgrades

Für Stakeholder im Unternehmen

• Anstatt auf ein festes Upgrade-Fenster zu warten, können Sie Funktionen freigeben, wenn sie fertig sind, und sie so schneller zum Kunden bringen. Da Sie während der Entwicklung ständig auf einem Staging-Server veröffentlichen, können interne Kunden die Änderungen sehen und sich am Entwicklungsprozess beteiligen.
• Manager sehen das Ergebnis der Arbeit schneller und der Fortschritt wird sichtbar, wenn Sie häufiger veröffentlichen
• Wenn ein Entwickler ein paar Stunden mehr benötigt, um sicherzustellen, dass die Funktion einwandfrei funktioniert, wird die Funktion ein paar Stunden später veröffentlicht und nicht, wenn sich das nächste Release-Fenster öffnet.
• Sysadmins müssen die Releases nicht selbst durchführen. Kleine, diskrete Feature-Releases ermöglichen eine einfachere Erkennung der Änderungen, die sich negativ auf das System ausgewirkt haben. 

Continuous-Deployment-Tools

Unit-Tests und Funktionstests versetzen den Code in so viele Ausführungsszenarien wie möglich, um sein Verhalten in der Produktion vorherzusagen. Unit-Testing-Frameworks bestehen unter anderem aus NUnit, TestNG und RSpec.
 
IT-Automatisierungs- und Konfigurationsmanagement-Tools wie Poppet und Ansible verwalten die Codebereitstellung und die Konfiguration von Hosting-Ressourcen. Tools wie Cucumber und Calabash können beim Einrichten von Integrations- und Akzeptanztools helfen.
 
Überwachungstools wie AppDynamics und Splunk können helfen, alle Änderungen in der Anwendung oder Infrastruktur zu verfolgen und zu melden. Leistung aufgrund des neuen Codes. Management-Tools wie PagerDuty können IT-Vorfallreaktionen auslösen. Die Überwachung und Reaktion auf Vorfälle für Continuous-Deployment-Setups sollte in Echtzeit erfolgen, um die Wiederherstellungszeit zu verkürzen, wenn es Probleme mit dem Code gibt.
 
Rollback-Funktionen sind im Bereitstellungs-Toolset unerlässlich, um unerwartete oder unerwünschte Auswirkungen von neuem Code in der Produktion zu erkennen und diese schneller zu beheben. Darüber hinaus können Canary-Bereitstellung und Sharding, Blue/Green-Bereitstellung, Feature-Flags oder -Umschalter und andere Bereitstellungssteuerungen für Organisationen nützlich sein, die sich vor Benutzerunterbrechungen durch Continuous Deployment schützen möchten.
 
Einige Anwendungen können in Containern wie Docker und Kubernetes bereitgestellt werden, um Updates von der zugrunde liegenden Infrastruktur zu isolieren.

Continuous Deployment mit Drupal

Eine Digitalagentur arbeitete mit Drupal 8, Composer, Github, Pantheon und CircleCI rund um Continuous Integration und Deployment. Das Projekt umfasste den Umzug vom internen Hosting in die Cloud (in diesem Fall Pantheon), den Umzug der Hauptseiten von Drupal 7 auf Drupal 8 und die Implementierung eines neuen Designs.

In die Cloud

Pantheon wurde als Cloud-Host für neue Drupal-Sites ausgewählt. Ursprünglich wurde es für Funktionen wie "Custom Upstreams", One-Click-Core-Updates, einfache Bereitstellungen zwischen Entwicklungs-, Test- und Live-Umgebungen, Multidevs und die Tatsache ausgewählt, dass jedes ein Git-Repo im Herzen ist. Terminus (Pantheon CLI-Tool) wurde stark genutzt und geschätzt.

Migration zu Drupal 8

Es konzentrierte sich auf zwei Haupt-Umbrella-Sites und eine News-Site, um beide Umbrella-Sites zu bedienen. Es wurde eine Inhaltsaktualisierung durchgeführt, die zeigte, dass nur Inhalte migriert werden müssen, sind die Nachrichtenartikel. Das Konfigurationsmanagement von Drupal 8 wurde als schöner als das von Drupal 7 empfunden.

Benutzerdefiniertes Design

Da Drupal nicht die einzige Webplattform ist, die sie verwendeten, erstellten sie anstelle eines Drupal-Themes ein plattformunabhängiges Projekt mit einem neuen Look and Feel. Es basierte auf der Zurb-Foundation und war nur HTML, CSS und JavaScript.
 
Grunt wurde als Build-Tool verwendet. Wenn sie also ein neues Release haben, würden sie einfach committen und zu Github pushen. Dies löst einen CircleCI-Workflow aus, der ein neues Release taggt und das Release-Artefakt als npm-Paket in Artifactory veröffentlicht. Von dort aus kann das npm-Paket in jedes Projekt, einschließlich Drupal, gezogen werden.
 
Es sollte beachtet werden, dass das veröffentlichte Paket nur die CSS-, JS-, Bibliotheken und andere Assets enthält. Nach der Veröffentlichung wird mit dem Paket und den entsprechenden HTML-Vorlagen auf einem Cloud-Host als Referenzimplementierung eine statische Site erstellt.

Bereitstellungsprozess

Sie hatten ein "Upstream"-Repo auf Github namens umbrella-upstream, das ein Composer-basiertes Drupal-8-Projekt mit einem benutzerdefinierten Installationsprofil bestehend aus benutzerdefinierten Modulen, package.json und Bereitstellungsskripten ist. Jede der Sites (umbrella-site X, umbrella-site Y usw.) befand sich ebenfalls in einem Github-Repo als Composer-basiertes Drupal-8-Projekt und hatte umbrella-upstream als Remote konfiguriert.
 
Wenn sie eine Änderung in das Upstream-Repo pushen, wird eine Reihe von CircleCI-Workflows gestartet, die einige Codeception-Akzeptanztests ausführen, und die Änderungen werden von umbrella-upstream zu jedem umbrella-site X/Y-Repo zusammengeführt.
 
Dann erstellt, testet und pusht ein weiterer CircleCI-Workflow eine vollständige Drupal-Umbrella-Site X/Y-Installation auf die entsprechende Pantheon-Site X/Y bis hinauf in die Testumgebung. Quicksilver-Hooks wurden verwendet, um alle Änderungen von Pantheon zurück zu den Site-Repos zu senden.

Der gesamte Workflow umfasste:

• Codeänderungen und Git-Commit im benutzerdefinierten Design-Repo
• Npm update custom-design -save-dev, Grunt und Git-Commit im Umbrella-Upstream-Repo

Schließlich werden die Änderungen in der Testumgebung jeder Site auf Pantheon angezeigt.

Fazit

Es ist von größter Bedeutung, dass Sie Software schnell und effektiv iterieren und bereitstellen. Continuous Deployment ist eine großartige Strategie für Software-Releases, bei der ein Code-Commit, der die automatisierte Testphase besteht, automatisch in die Produktionsumgebung freigegeben wird.
 
Die Drupal-Bereitstellung kann durch die Einbeziehung von Continuous Deployment in den Projektentwicklungsprozess in hohem Maße profitieren. Der größte Vorteil dabei ist, dass die Änderungen für die Benutzer der Anwendung sichtbar werden.
 
Opensense Labs hat sich der Bereitstellung eines hervorragenden digitalen Erlebnisses für Unternehmen mit seiner Servicepalette verschrieben.
 
Um Ihr nächstes Drupal-basiertes Projekt durch die Implementierung von Continuous Deployment äußerst effektiv zu gestalten, kontaktieren Sie uns unter [email protected]