Wie der Drupal-Support bei Droptica funktioniert

In meinem vorherigen Beitrag habe ich beschrieben, warum wir ein separates Drupal-Support-Team erstellt haben. In diesem Beitrag werde ich beschreiben, wie unser Drupal-Support-Team arbeitet.

Ziele des Drupal-Support-Teams

Das Drupal-Support-Team bei Droptica hat drei Hauptziele:

1. Alle Websites am Laufen halten

Viele unserer Kunden sind darauf angewiesen, dass ihre Websites betriebsbereit sind. Oftmals sind die Anwendungen, die wir betreuen, integraler Bestandteil des Geschäfts unserer Kunden. Ausfallzeiten bedeuten Beschwerden, entgangene Einnahmen usw. 

Unser Support-Team konzentriert sich darauf, sicherzustellen, dass die Websites funktionieren und schnell auf auftretende Probleme oder Fehler reagieren. 

2. Die Websites sicher halten

Sicherheitsupdates für Drupal-Core und Module erscheinen ständig. Dasselbe gilt für die Technologiestacks, auf denen Drupal läuft – Server-Software, PHP-Versionen usw. Unser Support-Team stellt sicher, dass alle Websites auf dem neuesten Stand sind und keine bekannten Sicherheitsanfälligkeiten aufweisen. 

Wenn ein Drupal-Sicherheitsupdate erscheint, müssen wir über 100 Websites so schnell wie möglich aktualisieren. Dazu haben wir optimierte Prozesse und Workflows entwickelt, die von unserem Support-Team gepflegt werden.

3. Bereitstellung kleiner Entwicklungsdienstleistungen

Viele Websites benötigen nach der anfänglichen Entwicklungsphase kein Vollzeit-Entwicklungsteam. Fast jede Website benötigt jedoch von Zeit zu Zeit etwas Arbeit. Entweder eine neue Landingpage, eine neue Integration oder vielleicht Bugfixing oder Problemlösung.

Solange der Entwicklungsaufwand nicht umfangreich ist, hilft unser Support-Team auch bei diesen Aufgaben. Wenn neue Funktionen einen größeren Aufwand erfordern, wird die Arbeit geplant und an eines unserer Teams von Drupal-Entwicklern übergeben.

Der Support-Prozess

Bei Droptica automatisieren wir so viel wie möglich. Um sicherzustellen, dass wir keine Zeit verschwenden und die vorhersehbarsten Ergebnisse liefern, folgen alle Websites demselben Prozess.

Es gibt eine automatisierte Testumgebung

Jede Website, die wir zur Unterstützung übernehmen, durchläuft einen Onboarding-Prozess, der es uns ermöglicht, sie in Zukunft einfach zu verwalten. Während des Onboardings erstellen wir Folgendes:

1. Eine replizierbare Entwicklungsumgebung auf Docker, die die Produktionsumgebung so weit wie möglich nachbildet. 
2. Eine automatisierte Testumgebung, die dem Kunden zur Verfügung steht (eine Testwebsite). Hier stellen wir unseren Kunden Arbeiten vor, die sie prüfen können, bevor sie in die Produktion gehen. Kunden können dies auch für ihre Test- und Schulungszwecke nutzen. Wenn Bedarf besteht, können wir mehrere solcher Klone der Website erstellen.
3. Einen automatisierten Prozess zum Duplizieren einer Produktionswebsite in Entwicklungs- und Testumgebungen. Dieser Prozess ermöglicht es uns, mit einem Klick die neueste Version der Produktionswebsite in jede Umgebung zu kopieren und neuen Code darauf zu implementieren. 
4. Einen automatisierten Bereitstellungsmechanismus, der es uns ermöglicht, neue Änderungen schnell und vorhersehbar in die Produktion zu veröffentlichen

Dank der Automatisierung können wir innerhalb weniger Minuten eine Produktionswebsite in die Entwicklung kopieren, einen Fehler überprüfen und eine Lösung dafür erstellen, sie in die Testumgebung verschieben, um die Bereitstellung zu testen, und sie auch dem Kunden präsentieren. Wenn die Änderung akzeptiert wird, kann sie schnell automatisch in die Produktion übernommen werden.

Ablauf von Support-Anfragen

Wir ermutigen unsere Kunden, Jira zu verwenden, aber einige bevorzugen E-Mail oder Skype. Unabhängig von der Kommunikationsmethode protokollieren wir jede Anfrage in Jira. Hier beginnt das Leben der Anfrage. Abhängig von Schweregrad, Dringlichkeit, Art der Anfrage und dem Support-Paket des Kunden wird das Ticket entsprechend geplant und wartet darauf, dass ein verfügbarer Entwickler es übernimmt. 

Nach mehreren Tests haben wir jetzt die folgenden Status in Jira, um die Phasen zu beschreiben, in denen sich das Ticket befinden kann:

1. To Do - Das Ticket ist neu. Niemand hat bisher daran gearbeitet.
2. Needs Work - Das Ticket wurde begonnen, ist aber noch nicht abgeschlossen und wird momentan nicht aktiv bearbeitet. Dies kann ein Ticket sein, das die Qualitätskontrolle nicht bestanden hat und zur Verbesserung zurückgegeben wurde, oder ein Ticket, das begonnen wurde, aber der Entwickler musste zu etwas Dringenderem wechseln.
3. In Progress - Ein Entwickler arbeitet derzeit aktiv an diesem Ticket. Dies geschieht in einem separaten Branch in Git, der nur dann mit dem Hauptbranch zusammengeführt wird, wenn er die QA bestanden hat. Dies stellt sicher, dass wir nur getestete und funktionierende Lösungen in die Produktion ausliefern.
4. Feedback/Impediment - Das Ticket benötigt Input vom Kunden oder jemand anderem (z. B. einem externen Anbieter) und wir warten auf weitere Informationen.
5. Code Review - Ein Entwickler hat die Arbeit abgeschlossen und einen Pull-Request mit Code erstellt. Dieser wartet nun auf die Code-Qualitätsprüfung. Ein erfahrener Entwickler wird den Code überprüfen, um festzustellen, ob er korrekt ist, sinnvoll ist und die Drupal-Standards einhält.
6. QA - Das Ticket hat die Code-Review bestanden und wird nun von unserem Testing-Team (Quality Assurance) getestet. Die Art der Tests kann von einfachen manuellen Überprüfungen bis hin zu umfangreichen automatisierten Regressionstests der Funktionalität und Erscheinung variieren. Üblicherweise wird QA automatisch eine Testversion der Website auf dem Entwicklerbranch des Core erstellen und alle notwendigen Tests durchführen. Wenn die Tests bestanden sind, wird der Kunde informiert, dass er die Lösung testen kann, wenn er möchte.
7. PO Review - (Produkt-Eigentümer-Überprüfung) - Wir glauben, dass wir die Arbeit abgeschlossen haben und präsentieren das Ticket dem Kunden zur Prüfung auf einer Testwebsite.
8. Ready To Deploy - Der Produkt-Eigentümer hat die Arbeit akzeptiert und sie ist bereit, in die Produktion überführt zu werden.
9. Done - Der Code ist in die Produktion übertragen. Die Arbeit an diesem bestimmten Ticket ist abgeschlossen.   

Das Obige beschreibt anschaulich, was mit jeder Anfrage passiert. Dank der Automatisierung können wir problemlos an verschiedenen Tickets gleichzeitig arbeiten, sie testen und sicher und vorhersehbar in die Produktion ausliefern. 

Websites unserer Kunden sind gut betreut.