Bei uns kann jeder deployen – Wie SHOPMACHER seinen Mitarbeitern die Angst vor dem Deployment nahm.

Bei uns kann jeder deployen …

Also kein Scherz jetzt, ich meine das ernst, wirklich jeder. Technisch gesehen ist das bei uns nämlich nur ein Tag anlegen und ein Klick im Jenkins und schon startet die automatische Buildpipeline. Aber wie haben wir das gemacht, dass selbst die Geschäftsführung theoretisch nach einem kurzen Briefing das nächste Release Paket für einen beliebigen Kunden deployen könnte? Im Grunde war das alles recht einfach, brachte aber seine Herausforderungen mit sich. 

Der Weg zur Agilität.

Wie viele Agenturen arbeitet auch SHOPMACHER mit seinen Kunden in einem agilen Umfeld. Das war nicht immer so. Früher haben wir für jeden Kunden ein Angebot auf Basis bestimmter Anforderungen erstellt, welches dann entwickelt und später irgendwie deployed wurde.

Ich erinnere mich noch gut daran, wie ich gen halb sechs morgens ins Büro kam um mittels eines SFTP-Clients das neueste Feature auf die verschiedenen Applikationsserver eines Kunden auszurollen, damit dieser dann ab acht Uhr morgens das neue Feature im Live System nutzen konnte.

Wie sich der ein oder andere gerade denken mag, ging das nicht immer ohne Probleme vonstatten und hat mir noch vor dem ersten Kaffee gerne mal die Schweißperlen auf die Stirn getrieben.

Die Deploymentkerze

Andere Kollegen gingen dabei sogar noch einen Schritt weiter. Sie waren nicht nur sehr früh im Büro sondern zündeten vor jedem Deployment auch noch eine Kerze an. Diese Deploymentkerze sollte Glück bringen und dafür sorgen, dass möglichst wenig Probleme beim Deployment auftreten. Rein logisch betrachtet ist sowas natürlich absoluter Quatsch und doch kamen mit angezündeter Deploymentkerze gefühlt deutlich weniger Bugs ans Licht als ohne.

Die Umstellung

Diese Zeit des Hoffen und Bangens endete, so dachten wir Anfangs, mit der Umstellung auf ein agiles Arbeitsmodell. Durch die Umstellung auf feste Entwicklungskontingente, welche der Kunde im Monat abnimmt (Retainer), Projekt-Teams, Sprints und die dazugehörigen Refinements sowie das Planning wurden individuelle Angebote nur noch sehr selten erstellt. Das führte dazu, dass wir in der Lage waren, Features und deren Deployment lange im Voraus zu planen, was sowohl uns als auch dem Kunden Sicherheit und eine Perspektive gab. Zudem wurde nicht mehr jedes Feature einzeln deployed, sondern wir bündelten mehrere Features zu Releases, welche der Kunde gesammelt abnahm und wir im Anschluss deployten.

Im Grunde eigentlich alles deutlich entspannter für die Entwickler, da diese sich auf die kommenden Releases gut vorbereiten und etwaige Gefahrenpotentiale im Vorfeld ausmachen könnten. Der Nachteil an der Bündelung der Features war allerdings, dass beim Deployment auch deutlich mehr schief gehen konnte, da die Anzahl der zu übertragenden Dateien mit der Anzahl der Features steigt. Somit traten bei der althergebrachten Deploymentweise deutlich mehr Fehler auf als zuvor, was weder dem Kunden noch uns als Agentur die Freudentränen ins Gesicht trieb. 

Problem und Lösung

Für dieses Problem brauchten wir eine Lösung. Diese war so einfach wie genial und lautete Automation. Desto mehr wir den Deployment Prozess vom Faktor Mensch lösten, desto robuster und fehlerunabhäniger wurde die eigentliche Aufgabe. Weiterhin stieg somit auch die Anzahl der Personen, die ein Live Deployment durchführen konnten. War diese Aufgabe früher nur den erfahrensten Entwicklern vorbehalten, deployen heute bei uns auch Auszubildende. Natürlich immer unter dem wachsamen Auge eines erfahrenernen Kollegen, aber sie tun es.  

Der neue Prozess

Was mussten wir dafür an diesem Prozess ändern ? Hierfür ist es hilfreich, im Groben zu verstehen, wie die Online Shops, die wir betreuen, im Grunde aufgebaut sind. In über 90% der Fälle handelt es sich um ein Multiserver Setup. Das bedeutet, die eigentliche Shopsoftware liegt auf mehreren Servern. Vor diesen Servern ist ein sogenannter Loadbalancer (Lastenverteiler) vorgeschaltet, welcher den Nutzer des Onlineshops je nach Auslastung der einzelnen Systeme auf den Server leitet, der gerade am wenigsten zu tun hat. Dies ermöglicht es, im Bedarfsfall einfach weitere Server “daneben” zu stellen, um das System noch performanter zu machen, z.B. wenn eine TV-Werbung geplant ist oder zum Black-Friday ein Newsletter versendet wird.

Um nun die Änderungen am Shop möglichst zeitgleich auf alle Server zu verteilen, haben wir uns folgenden Prozess ausgedacht. Bevor ein Release veröffentlicht wird, hat der Kunde die Möglichkeit, dies auf einem Abnahmesystem zu testen und etwaige Unstimmigkeiten im Vorfeld anzumerken und korrigieren zu lassen. Dieses System nennen wir Staging-System, welches aus unserem Source-Control-Management, die Stelle an der die Entwickler den neu erstellten Quellcode ablegen, befüllt wird.

Hat der Kunde das Release abgenommen, kann die Übertragung zum Live-System beginnen. Hierfür markieren wir den aktuellsten Stand der Entwicklung im Source-Control-Management mit einer Art Stempel, ein sogenanntes Tag. Anhand diese Tags weiß die Automation später, welchen Quellcode Sie nehmen muss, um diesen dann auf das Live System zu übertragen. Nachdem diese Markierung gesetzt ist, kann es auch schon losgehen.

Kennen Sie Jenkins ?

Ab hier übernimmt Jenkins die Arbeit für uns. Jenkins ist ein Programm, welches ursprünglich von  Sun Microsystems für deren Deployment Prozess entwickelt wurde. Damit lassen sich Automatisierungsprozesse sehr einfach und gut abbilden. Aber wie deployed denn nun der Jenkins die Änderungen auf das Livesystem? Mit Hilfe von Ameisen. Nein, keine herkömmichlen Ameisen, sondern mit dem Programm namens Ansible.

Mit Ansible kann man über ein sehr einfaches Dateiformat einen Ablauf definieren, welcher dann ausgeführt wird. Dieser Ablauf nennt sich Playbook. Man kann mehrere dieser Playbooks verschachteln und so eine Vielzahl von Szenarien abbilden. Genau das machen wir auch bei einem Deployment.

Der Jenkins führt ein Ansible Playbook aus, welches dann weitere Playbooks ausführt. Jedes Playbook hat eine bestimmte Aufgabe, z.B. den Quellcode mit dem zuvor angelegten Tag aus dem Source-Control-Management zu holen, damit dieser dann auf die einzelnen Server verteilt werden kann.

Alles Ok, nix Ok

Wurden alle Aufgaben bzw. Playbooks erfolgreich durchgeführt, ist alles Ok, sprich das Deployment war erfolgreich. Geht irgendwo irgendwas schief, ist das Deployment fehlgeschlagen und der Jenkins gibt eine Fehlermeldung aus, welche dann in der Regel den Grund des Fehlschlags enthält. Hier greift zudem einer der vielen Vorteile, die eine Automation mit sich bringt. Wir haben das Deployment so gebaut, dass erst wenn alle Playbooks erfolgreich durchgelaufen sind die Nutzer auf den neuen Programmcode geleitet werden. Somit bleibt der “alte” Onlineshop so lange aktiv bis wir uns sicher sein können, dass alles bereit und funktional ist. 

Die Prozesse im Vergleich

Wenn man das mit unserem alten Vorgehen vergleicht, wo wir die Dateien noch von Hand übertragen hatten, wird einem schnell bewusst, wie viel weniger Arbeit ein einzelnes Deployment nun macht was sich natürlich auch positiv auf das Stresslevel der Entwickler und die Zufriedenheit der Kunden auswirkt. Besonders Kunden mit viel Traffic auf ihrem Shop sind von unserer neuen Vorgehensweise überzeugt, da Ausfälle im Shopsystem so auf ein Minimum reduziert werden.

Der Workflow im Detail

Für alle, die nun gerne etwas mehr Details zu dem eigentlichen Workflow haben möchten, lehnt euch zurück und gönnt euch die folgenden Zeilen. Diese setzen allerdings etwas Fachwissen voraus. Wer also zwischendurch nur noch Bahnhof versteht, darf diesen Teil gern überspringen und zum Fazit übergehen.

Vorbereiten

Wie haben wir das Deployment also im Detail gelöst. Wie oben schon angesprochen checken wir zuerst das letzte Tag aus, das im Deployment hinterlegt ist. Dieses Tag wird vom Entwickler, der das Deployment anstößt, in einem separaten Sub-Repository eingetragen. Dieses Repository enthält neben dem Tag noch weitere Informationen zum Environment auf dem deployed wird. Wir haben uns für diesen Weg entschieden, da wir einen Deployment Prozess für alle Systeme nutzen wollen und das Rad nicht für Stage und Live jeweils neu erfinden möchten.

Verteilen

Der Code, der an dem Tag hängt, wird jeweils auf allen Applikationsservern in einem separaten Build Verzeichnis ausgecheckt. Dieses Verzeichnis hat den Namen des Tags. Je nach Komplexität des Shops werden hier unterschiedliche Repositories zu einem großen Klumpen Shop zusammen gemerged. Danach werden die shop spezifischen Konfigurationen gesetzt und die Datenbank Migrationen durchgeführt. Dieser Schritt ist recht heikel, weil wir bei einem Live Deployment natürlich auf der Live Datenbank schreiben. Sprich, wenn wir Features oder Änderungen ausrollen, die den Betrieb des Shop gefährden können, müssen wir uns zuvor überlegen, wie wir hier vorgehen. Mögliche Lösungen sind hier z.B. Append Only Lösungen die in der Entwicklung vorgesehen werden welche dann dafür sorgen, dass man immer Abwärtskompatibel bleibt. Alternativ kann man auch auf eine ganz klassische Wartungsseite zurückgreifen, welche den Online Shop kurzzeitig für die Kunden unerreichbar macht. Die Möglichkeiten sind hier sehr vielfältig. 

Testen und Live-schalten

Nach dem der “neue” Shop also in dem neuen Verzeichnis zusammengebaut wurde, laufen die automatisierten Tests. Diese stellen die Grundfunktionalität des Shops sicher. Dies können sowohl Unit Tests als auch Akzeptanztest sein, welche dann durch ein Testframework durchgeführt werden. Laufen die Test auf allen Applikationsservern durch, sind wir „ready to roll“ und wir können die neue Version live schalten. Dies ist dann nur noch ein total kleiner Aufwand, da wir ja eine Kopie des Shops auf allen Applikationsserver gebaut haben. Somit, ändern wir das nur noch das Document Root der Webserver auf das neue Tag-Verzeichnis und die neue Version ist Live. Dies kann man entweder direkt über die Webserver Konfiguration oder bei Bedarf über einen Symlink machen. Beide Vorgehen sind beliebt.

Das Ändern des Document Roots hat zudem noch den Vorteil, dass ein Rollback zu der vorherigen Version jederzeit möglich ist. Selbst nach Tagen können wir auf Wunsch des Kunden das Release einfach zurückrollen.

Fazit

Ein automatisiertes Deployment sorgt nicht nur für weniger Fehler und einfache Rollbacks. Es wirkt sich vor allem auch auf Stimmung sowie die Gesundheit der Entwickler und damit auf das gesamte Unternehmen aus. Durch die Reduzierung des manuellen Aufwands beim Deployment muss deutlich weniger beachtet werden, was für mehr Sicherheit und einen niedrigeren Puls beim Entwickler sorgt.

Die Entscheidung, unser Deployment zu automatisieren, hat bei uns für eine Win-Win-Win Situation gesorgt. Win für den Kunden, weil ein Deployment weniger Zeit in Anspruch nimmt und somit die Kosten senkt. Win für den Entwickler, welcher nicht in aller Herrgottsfrühe aufstehen muss, um wie in den 90er Jahren Dateien auf den Servern von A nach B zu schieben –  von dem Stress, unter den wir den Entwickler mit so einem Vorgehen setzen, mal ganz abgesehen. Und Win für SHOPMACHER, weil sich die Entwickler nun wieder auf die Entwicklung konzentrieren können, was die Motivation steigert.

Denn wie es die Berufsbezeichnung schon erahnen lässt, möchten Entwickler entwickeln. Wenn sie die Zeit auf der Arbeit mit deployen verbringen wollen würden, wären sie Deployer geworden.