Viele Entwickler setzen mittlerweile auf die Unterstützung von automatisierten Tests und gewährleisten dadurch ein frühe Fehlererkennung, geringere Kosten bei der Behebung und schlussendlich eine hohe Qualität. Dennoch können Fehler nicht vollkommen ausgeschlossen werden.
Einer der Gründe hierfür ist, dass die Tests in der Regel nur in Testsystemen ausgeführt werden. Somit ist eine Aussage hinsichtlich der Funktionsweise im Produktivsystem nicht gegeben. Anwender überraschen uns Entwickler gerne mit unkonventionellen Eingaben oder einer eigenwilligen Bedienung der Software. Dies kann unter Umständen zu schiefen Datenständen führen. Was also in der Entwicklungs- bzw. Testumgebung funktioniert, muss dies noch lange nicht in der Produktivumgebung tun. Was kann man nun unternehmen, um eine bessere Aussage treffen zu können?
Eine Möglichkeit besteht im Blue Green Deployment. Dabei besteht das Produktivsystem zweimal. Einmal als blaue, einmal als grüne Linie. Aktiv ist immer nur eines der beiden Systeme. Das inaktive System kann für Tests herangezogen werden. Dabei können die Systeme auf unterschiedlicher (aber ähnlicher) Hardware oder VMs laufen.
Ein neues Release wird dabei immer am inaktiven System eingespielt und getestet. Sind alle Tests erfolgreich und stehen alle Funktionen zur Verfügung, wird das inaktive zum aktiven System und umgekehrt. In anderen Worten: War das blaue System aktiv und das grüne System inaktiv, dann erhielt das grüne System das Update und wurde nach erfolgreichen Tests aktiv. Nun ist das blaue System inaktiv und erhält das nächste kommende Update.
Dies bietet natürlich auch noch weitere Vorteile. So ist es sehr schnell möglich, wieder auf die alte Version zurückzugehen (Rollback). Zudem steht ein zweites System bei Ausfällen (Hardware etc.) zur Verfügung.
Die zusätzliche Sicherheit bringt jedoch einige Herausforderungen hinsichtlich Infrastruktur, Deploymentprozess, aber auch der Entwicklung (z.B. Umgang mit Schemaänderungen an der Datenbank) mit sich. Belohnt wird man durch eine höhere Ausfallssicherheit und einer möglichen (verbesserten) Aussage über die Funktionsfähigkeit eines neuen Releases im Produktivsystem.
Darauf aufbauend kann ein Canary Deployment eine noch bessere Aussagekraft im Produktiveinsatz geben.
Credit: Server-Icon von FontAwesome / CC Attribution 4.0 International, alle anderen Icons von Microsoft Powerpoint.