In Blue Green Deployment habe ich einen Ansatz beschrieben, wie neue Releases in Produktivumgebungen vor der Aktivierung getestet werden können. Daraus lässt sich mit höherer Wahrscheinlichkeit auf die Funktionsfähigkeit eines Releases rückschließen. Allerdings wird nur getestet. Wie stabil und performant die Software läuft, kann nicht beurteilt werden. Eine Hilfe stellen Canary Deployments dar.
Canary Deployment (Kanarienvogel) hat den namentlichen Ursprung in den alten Kohleminen. Als Frühwarnsystem vor giftigen Gasen, haben die Minenarbeiter Kanarienvögel in Käfigen aufgestellt. Traten giftige Gase aus, sind die Kanarienvögel gestorben und die Arbeiter konnten sich noch schnell in Sicherheit bringen.
Wie funktioniert aber nun ein Canary Deployment?
Es gibt – wie auch beim Blue Green Deployment – zumindest zwei Produktivsysteme. Eines der beiden System (oder Teile davon) erhalten Updates. Nun kann der aktualisierte Part getestet werden (sowohl automatisiert, als auch manuell). Zudem wird ein zuvor definierter Teil des Traffics über das aktualisierte System geleitet.
Durch sukzessives Umleiten und Belasten des neuen Systems, werden aussagekräftige Hinweise über die Funktionsfähigkeit (auch unter Last) gegeben.
Ein Beispiel: Es wird festgelegt, dass nach der Aktualisierung, 2% des Traffics über das neue System geleitet werden. Treten keine Probleme auf, kann der Anteil erhöht werden. Treten Probleme auf, sind maximal 2% der Benutzer davon betroffen. Ein Rollback ist sofort möglich.
Mit diesem Aufbau steht also ein Frühwarnsystem zur Verfügung. Wir erhalten mehr Sicherheit und bei Problemen ist nur ein Bruchteil der Benutzer betroffen.
Einher geht allerdings auch ein infrastruktureller Aufwand und eine erhöhte Komplexität.