Wie wir Software entwickeln Teil 4: Continuous Deployment

Aus unserer Sicht gibt es nur einen einzigen richtigen Zeitpunkt, um ein neues Feature auf den Server auszuspielen: wenn es fertig ist. Nicht irgendwann, sondern gleich. Warum sollte man auch warten? Die Arbeit ist getan, das Feature ist getestet und Entwickler*innen, Product Owner*innen und Kund*innen sind sich einig, dass es der Website Wert hinzufügt. Also los! 

Das funktioniert natürlich nur, wenn durch das Deployment auf den Server kein riesiger Aufwand entsteht. Genau dies haben wir im Teil 3 dieser Serie aber erreicht: wir können vollautomatisch den Code inkl. aller Abhängigkeiten zusammenbauen und auf einen Server deployen. Bingo! 

Nun könnten wir uns zurücklehnen, eine Tasse Kaffee schlürfen und ein weiteres Marketing-Buzzword abhaken. Aber so funktionieren wir nicht. 

Ernten, was wir säen! 

Im vorherigen Teil dieser Serie habe ich dargelegt, dass es unserer Build-Chain ziemlich egal ist, auf welchen Server wir die Website ausliefern, solange dieser erreichbar ist und wir alle Informationen haben, die wir benötigen. 

Gleichzeitig wäre es großartig, wenn wir für die interne Qualitätssicherung und für den Review-Termin mit den Kund*innen eine Umgebung hätten, auf der wir einzelne Features besprechen, testen und abnehmen lassen könnten. 

Und natürlich haben wir genau dies gebaut: Unseren Review-Server. 

Sobald ein*e Entwickler*in die Arbeit an einem Feature in unsere Versionsverwaltung übermittelt, läuft unsere Buildchain los und baut, was das Zeug hält. Neben den vielen Tests, ob der*die Entwickler*in sich an die Coding-Guidelines gehalten hat und der Code sauber ist, wird nun eine eigenständige Instanz aufgebaut, die sich von der aktuellen Produktionsseite nur in einem Detail unterscheidet: Dem Feature, das der*die Entwickler*in gerade bearbeitet hat.

Review Server mit WOW-Effekt

Viele unserer Kund*innen sind begeistert von diesem Tool - nur wenige Minuten, nachdem der Entwickler seine Arbeit übermittelt hat, steht eine komplett eigenständige Version der Website zur Verfügung, inkl. eigener Datenbank, allen Dateien und natürlich einem SSL-Zertifikat. Damit Google & Co. diese nicht indizieren, ist diese durch einen Passwortschutz gesichert. 

Wir können einzelne Konfigurationen gezielt verändern. So liefern wir E-Mails aus Formularen auf dem Review-Server oftmals nicht beim eigentlichen Mailserver ein, sondern nutzen ein Mailtrap-Tool oder -Service. Damit können die E-Mails manuell eingesehen und automatisch getestet werden. Auch API-Anbindungen oder Solr-Server für den Suchindex werden häufig auf eine Testumgebung konfiguriert, um keine produktionsrelevanten Daten durcheinander zu bringen. 

Jede Änderung an der Website wird in einer eigenen Review-Instanz bereitgestellt und kann von dem*der Kund*in nach Belieben auf Herz und Nieren geprüft werden. Durch die aktuellen Daten ist zu jeder Zeit klar, was diese Änderung bewirkt und wie die Live-Instanz aussehen wird, sobald dieses Feature abgenommen und ausgespielt wurde.

Und wenn es mal länger dauert?

Da die Instanzen unseres Review-Servers komplett autark sind, haben wir auch keine Begrenzung in Anzahl der Instanzen, die wir automatisch erstellen. Arbeiten wir mit Hochdruck an Projekten, ist es nicht unüblich, dass wir ein halbes Dutzend oder mehr Review-Instanzen eines Projekts gleichzeitig aktiv haben. Benötigt eine Abteilung eines*einer Kund*in etwas länger mit der Prüfung und Abnahme des neuen Codes, lassen wir die Instanz einfach länger aktiv. Kleinere Features sind nur wenige Stunden aktiv, wenn der*die Kund*in schnell Rückmeldung gibt und grünes Licht gibt. 

Zur Automatisierung gehört natürlich auch, dass wir die Instanzen wieder löschen, wenn sie nicht mehr gebraucht werden - wird der Code in den Hauptbranch integriert und das zugehörige Ticket geschlossen, wird auch die Instanz gelöscht. 

Datenschutz wird groß geschrieben

Sind in der Produktionsumgebung datenschutzrelevante Daten enthalten, z.B. Teilnehmerdaten eines Gewinnspiels, können wir diese für den Einsatz auf dem Review-Server und den Entwicklungsrechnern anonymisieren. Damit stellen wir sicher, dass auf den Entwicklerumgebungen und dem Review-Server keine schützenswerten Daten gespeichert werden, die Tests aber auf einer Umgebung durchgeführt werden können, die sehr nahe an die Echtdaten herankommen. Es macht beim Testen eben einen Unterschied, ob 20 Testdatensätze im System sind oder mehrere Hunderttausend Datensätze im Realbetrieb. 

Unsere Kund*innen sind begeistert von den Möglichkeiten unseres Review-Servers. Wenige Minuten nach Fertigstellung eines Features steht eine Kopie der aktuellen Website zur Verfügung, die sich von der tatsächlichen Produktions-Website nur durch diese eine Änderung unterscheidet, die getestet werden soll. Das erleichtert die Prüfung und Abnahme ganz erheblich und beschleunigt den Entwicklungsprozess. Alle Stakeholder können sehen und ausprobieren, was passiert, wenn diese Änderung akzeptiert und auf die Produktions-Umgebung ausgespielt wird.