Aber ganz unabh\u00e4ngig von der Strategie d\u00fcrfen Sie nicht vergessen, dass sich Probleme bei der Bereitstellung nicht vermeiden lassen. Ein \u201eMerge\u201c kann schief gehen, es k\u00f6nnen Bugs auftreten oder ein menschlicher Fehler kann in der Produktion problematisch werden. Der Punkt ist, dass Sie sich von der Suche nach der perfekten Bereitstellungsstrategie nicht verr\u00fcckt machen lassen sollten. Denn diese Strategie gibt es nicht.<\/p>\n
Versuchen Sie stattdessen, eine Strategie zu finden, die \u00e4u\u00dferst belastbar ist und sich an Ihre Arbeitsweise anpassen l\u00e4sst. Anstatt zu versuchen, unvermeidliche Fehler zu vermeiden, sollten Sie den Code so bereitstellen, dass Fehler minimiert werden und Sie schnell reagieren k\u00f6nnen, wenn sie dann doch auftreten. F\u00fcr viele Teams liegt die L\u00f6sung dieses Problems in Canary Deployments.<\/p>\n
Canary Deployments k\u00f6nnen Ihnen helfen, Ihren besten Code so effizient wie m\u00f6glich in die Produktion zu geben. In diesem Artikel werden wir erkl\u00e4ren, was Canary Deployments sind und was nicht. Wir gehen auf die Pros und Kontras von Canary Deployments ein, vergleichen sie mit anderen Bereitstellungsstrategien und zeigen Ihnen, wie Sie mit Ihrem Team ganz einfach Canary Deployments durchf\u00fchren k\u00f6nnen.<\/p>\n In diesem Artikel greifen wir folgende Punkte auf:<\/p>\n [toc]<\/p>\n Canary Deployments sind Best Practice f\u00fcr Teams, die sich f\u00fcr den Prozess Continuous Delivery<\/strong> entschieden haben. Bei einem Canary Deployment wird ein neues Feature zun\u00e4chst einer kleinen Teilgruppe von UserInnen zur Verf\u00fcgung gestellt. Das neue Feature wird je nach Traffic einige Minuten bis mehrere Stunden lang \u00fcberwacht, oder zumindest so lange, bis aussagekr\u00e4ftige Daten vorhanden sind. Wenn das Team ein Problem feststellt, wird das neue Feature schnell zur\u00fcckgezogen. Werden keine Probleme festgestellt, wird das Feature f\u00fcr alle UserInnen freigeschaltet.<\/p>\n Der Begriff \u201eCanary Deployment\u201c hat eine faszinierende Geschichte. Er ist auf die englische Redewendung \u201eCanary in a coal mine<\/a>\u201c (Kanarienvogel im Kohlebergwerk) zur\u00fcckzuf\u00fchren, als Kanarienv\u00f6gel oder andere kleine Singv\u00f6gel in Kohlebergwerken als Fr\u00fchwarnsystem eingesetzt wurden. Die Bergleute brachten V\u00f6gel in K\u00e4figen unter Tage. Wenn die V\u00f6gel erkrankten oder starben, war dies ein Warnhinweis daf\u00fcr, dass sich geruchlose giftige Gase, wie Kohlenmonoxid, ausbreiteten. Ein unmenschliches, aber wirksames Verfahren in Gro\u00dfbritannien und den USA, bis die Kanarienv\u00f6gel 1986 durch elektronische Sensoren ersetzt wurden.<\/p>\n Ein Canary Deployment macht aus einer Teilgruppe von UserInnen<\/strong> \u2013 idealerweise eine fehlertolerante Menge \u2013 ein eigenes Fr\u00fchwarnsystem. Diese Gruppe von UserInnen identifiziert Bugs, fehlerhafte Features und nicht-intuitive Features, bevor Ihre Software einer gr\u00f6\u00dferen Zielgruppe zug\u00e4nglich gemacht wird.<\/p>\n Ihre Canary UserInnen k\u00f6nnen selbst identifizierte Early Adopters sein, ein demografisch festgelegtes Zielsegment, eine zufallsbedingte Stichprobe, d.\u00a0h. ein Mix aus UserInnen, der am sinnvollsten ist, um Ihr neues Feature in der Produktion zu \u00fcberpr\u00fcfen.<\/p>\n Bei den \u00dcberlegungen zu Canary Deployments kann es hilfreich sein, an das Risikomanagement zu denken. Sie k\u00f6nnen neue, interessante Features regelm\u00e4\u00dfiger einf\u00fchren, ohne sich Sorgen machen zu m\u00fcssen, ob sich eins der neuen Features auf die User Experience aller UserInnen negativ auswirkt.<\/p>\n Die Begriffe \u201eCanary Release\u201c und \u201eCanary Deployment\u201c werden gelegentlich auch wie Synonyme gebraucht. Aber in DevOps m\u00fcssen sie unterschieden werden. Eine Canary Release ist ein Test Build einer vollst\u00e4ndigen Applikation.<\/strong> Beispielsweise ein n\u00e4chtlicher Release oder eine Beta-Version.<\/p>\n Manche Teams ver\u00f6ffentlichen Canary Releases oft in der Hoffnung, dass Early Adopters und Power UserInnen, die mit Entwicklungsprozessen besser vertraut sind, die neue Applikation herunterladen, um sie in der Praxis zu testen. Die Browser-Teams von Mozilla und Google und viele andere sind von dieser Release-Strategie begeistert.<\/p>\n Canary Deployments ihrerseits sind das, was wir bereits beschrieben haben. Ein Team ver\u00f6ffentlicht neue Features in der Produktion f\u00fcr Early Adopters oder verschiedene Teilgruppen von UserInnen, die \u00fcber einen Load Balancer oder ein Feature Flag auf die neue Software geleitet werden.<\/strong> Der Gro\u00dfteil der UserInnen sieht weiterhin die aktuelle, stabile Software.<\/p>\n Canary Deployments k\u00f6nnen als Release Strategie erfolgversprechend und effektiv sein. Aber sie sind nicht f\u00fcr jedes m\u00f6gliche Szenario die richtige Strategie. Gehen wir auf einige Pros und Kontras von Canary Deployments<\/strong> ein, damit Sie besser entscheiden k\u00f6nnen, ob sie f\u00fcr Ihr DevOps-Team sinnvoll sind.<\/p>\n Unterst\u00fctzung von CI\/CD-Prozessen<\/strong><\/p>\n Canary Deployments bewirken ein schnelleres Feedback zu neuen Features in Produktion. DevOps-Teams erhalten reale Nutzungsdaten schneller<\/strong>, wodurch sie die n\u00e4chsten Features schneller und deutlich effektiver verfeinern und integrieren k\u00f6nnen. Solche kurzen Entwicklungsschleifen sind eines der Markenzeichen von Continuous Integration\/Continuous Delivery<\/a>.<\/p>\n Granulare Kontrolle \u00fcber Feature-Bereitstellungen<\/strong><\/p>\n Wenn Ihr Team zu kleineren, regelm\u00e4\u00dfigen Feature-Bereitstellungen schreitet, verringern Sie die Gefahr, dass Ihr Arbeitsablauf durch Fehler unterbrochen wird<\/strong>. Nicht viele UserInnen werden von einem Fehler im Canary Deployment betroffen sein. Diesen Fehler zu beheben, wird nur eine geringf\u00fcgige Angelegenheit sein. Nicht alle Ihre UserInnen sind betroffen und Sie m\u00fcssen keine KollegInnen von der geplanten Arbeit abziehen, um ein gr\u00f6\u00dferes Produktionsproblem zu l\u00f6sen.<\/p>\n Realit\u00e4tsnahe Tests<\/strong><\/p>\n Interne Tests haben ihre Berechtigung, sind aber kein Ersatz f\u00fcr Test von Applikationen bei realen UserInnen. Canary Deployments sind eine ausgezeichnete Strategie f\u00fcr Tests in einem kleineren Umfang unter realen Bedingungen<\/a>, ohne die erheblichen Risiken, die Sie eingehen, wenn Sie eine v\u00f6llig neue Applikation in Produktion geben.<\/p>\n Schnell verbessertes Engagement<\/strong><\/p>\n Neben besseren technischen Tests k\u00f6nnen Sie mit Canary Deployments auch schnell feststellen, wie UserInnen mit Ihren neuen Features umgehen<\/strong>. Werden die Sessions l\u00e4nger? Steigen die Kennzahlen f\u00fcr ihr Engagement in diesem Canary Deployment? Wenn keine Fehler gefunden werden, k\u00f6nnen Sie das Feature allen UserInnen anzeigen.<\/p>\n Sie m\u00fcssen nicht warten, bis der Test einer umfangreichen Bereitstellung abgeschlossen ist. Binden Sie diese UserInnen ein und fahren Sie mit den n\u00e4chsten Features fort.<\/p>\n Mehr Daten f\u00fcr Business Cases<\/strong><\/p>\n Entwickler m\u00f6gen zwar den Wert ihres Codes erkennen, DevOps-Teams aber m\u00fcssen gegen\u00fcber der Gesch\u00e4ftsleitung und dem gesamten Unternehmen begr\u00fcnden, warum sie mehr Ressourcen brauchen.<\/p>\n Canary Deployments geben schnell Aufschluss dar\u00fcber, welche Nachfrage f\u00fcr neue Features bestehen k\u00f6nnte.<\/strong> F\u00fchren Sie ein Canary Deployment f\u00fcr ein \u00fcberzeugendes neues Feature bei einer kleinen Gruppe einflussreicher UserInnen durch, damit sie dar\u00fcber sprechen k\u00f6nnen. Nutzen Sie Kennzahlen f\u00fcr Engagement und Werbung, um Argumente vorzubringen, warum Sie eine gr\u00f6\u00dfere neue Initiative in Verbindung mit diesem Feature vorantreiben wollen.<\/p>\n St\u00e4rkeres Risikomanagement<\/strong><\/p>\n Canary Deployments sind im Grunde genommen eine Reihe von Mikrotests. Wenn Sie schrittweise neue Features einf\u00fchren und sie sukzessive mit Canary-Tests \u00fcberpr\u00fcfen, k\u00f6nnen Sie die Gesamtkosten von Fehlern oder gr\u00f6\u00dfere Systemprobleme erheblich reduzieren. Sie werden niemals eine gr\u00f6\u00dfere Version zur\u00fccknehmen m\u00fcssen, einen PR-Schaden erleiden und eine gro\u00dfe und komplizierte Codebase \u00fcberarbeiten m\u00fcssen.<\/p>\n Mehr Betriebskosten<\/strong><\/p>\n Wie jeder komplexe Prozess haben auch Canary Deployments einige Nachteile. Wenn Sie einen Load Balancer zur Aufteilung von UserInnen f\u00fcr ein Canary Deployment verwenden m\u00f6chten, brauchen Sie eine zus\u00e4tzliche Infrastruktur und m\u00fcssen einen zus\u00e4tzlichen Verwaltungsaufwand betreiben.<\/p>\n In diesem Szenario erstellen Sie eine zweite Produktionsumgebung und ein zweites Backend neben Ihrer prim\u00e4ren Umgebung. Sie haben dann zwei Codebases, zwei App-Server, u.\u00a0U. zwei Webserver und eine Netzwerkinfrastruktur, die gewartet werden muss.<\/p>\n Alternativ dazu verwenden viele DevOps-Teams Feature Flags, um ihre Canary Deployments auf einem einzigen System zu verwalten. Ein Feature Flag kann UserInnen in einen Canary-Test w\u00e4hrend der Laufzeit innerhalb einer einzigen Codebasis aufteilen. Canary-UserInnen sehen das neue Feature, w\u00e4hrend alle anderen den existierenden Code ausf\u00fchren.<\/p>\n Die Bereitstellung lokaler Applikationen: keine leichte Aufgabe<\/strong><\/p>\n Wenn Sie eine lokal installierte Applikation entwickeln, laufen Sie Gefahr, dass die UserInnen ein manuelles Update vornehmen m\u00fcssen, um die neueste Version Ihrer Software zu erhalten. Wenn Ihr Canary Deployment in diesem letzten Update enthalten ist, wird Ihr neues Feature m\u00f6glicherweise nicht auf allen Client-Systemen installiert, die Sie aber f\u00fcr gute Testergebnisse brauchen.<\/p>\n Mit anderen Worten: Je mehr Ihre Software clientseitig l\u00e4uft, desto weniger ist sie f\u00fcr Canary Deployments geeignet. Ein vollst\u00e4ndiges Canary-Release k\u00f6nnte sich hier besser eignen, um reale Testergebnisse zu erhalten.<\/p>\n UserInnen werden weiterhin mit Softwareproblemen konfrontiert<\/strong><\/p>\n Ein Canary Deployment soll ein neues Feature zwar nur einigen wenigen UserInnen pr\u00e4sentieren und die breitere User Base auslassen, konfrontiert aber End-UserInnen weiterhin mit einem Code, der nicht ausgiebig getestet wurde. Wenn ein Ausfall eines bestimmten Features bei nur wenigen UserInnen schon zu gro\u00dfe negative Auswirkungen f\u00fcr Ihr Unternehmen hat, sollten Sie auf ein Canary Deployment verzichten und strengere interne Tests durchf\u00fchren.<\/p>\n Canary Deployments sind zwar eine ausgezeichnete Strategie f\u00fcr Unternehmen, die st\u00e4ndig auf Experimente und Innovationen setzen, sind aber nicht f\u00fcr jeden geeignet. Canary Deployments sind m\u00f6glicherweise nicht die richtige Strategie, wenn:<\/p>\n Canary Deployments sind nur eine m\u00f6gliche Bereitstellungsstrategie f\u00fcr Ihr Team. Sie werden auch oft mit anderen \u00e4hnlichen, aber unterschiedlichen Prozessen wie A\/B-Tests verwechselt. Sehen wir uns an, wie sich Canary Deployments mit anderen Bereitstellungsstrategien und \u00e4hnlichen Prozessen vergleichen lassen, mit denen sie oft verwechselt werden.<\/p>\n Canary Deployments vs. A\/B-Tests<\/strong><\/p>\n Sowohl bei Canary Deployments als auch bei A\/B-Tests werden mehrere Produktionsumgebungen oder mehrere mit Flags versehene Codepfade zum Testen verwendet, wobei aber jedes Mal ein anderes Ziel verfolgt wird. DevOps-Teams nutzen Canary Deployments, um festzustellen, ob bei einer neuen Software technische Probleme vorliegen oder bei der Usability Schwierigkeiten bestehen. Bei einem A\/B-Test werden zwei verschiedene funktionierende Varianten f\u00fcr bestimmte Punkte wie Usability und Engagement sowie andere UX-Kennzahlen verglichen<\/strong>, um festzustellen, welche unter bestimmten Bedingungen besser abschneidet.<\/p>\n Canary Deployments vs. Blue-Green Deployments<\/strong><\/p>\n Canary Deployments werden auch mit Blue-Green Deployments verwechselt. In beiden F\u00e4llen k\u00f6nnen parallele Produktionsumgebungen verwendet werden \u2013 die mit einem Load Balancer oder Feature Flag verwaltet werden \u2013 um das Risiko von Softwareproblemen zu mindern.<\/p>\n Bei einem Blue-Green Deployment starten diese Umgebungen identisch, aber nur eine empf\u00e4ngt Traffic (der blaue Server). Ihr Team ver\u00f6ffentlicht ein neues Feature f\u00fcr die Hot Backup-Umgebung (den gr\u00fcnen Server). Dann verlagert der Router, das Feature Flag usw. nach und nach neue UserInnen Sessions von dem blauen auf den gr\u00fcnen Server, bis der gesamte Traffic zu 100 % auf dem gr\u00fcnen Server liegt. Nach dem Cutover aktualisiert das Team den jetzt alten blauen Server mit dem neuen Feature, der dann zur Hot Backup-Umgebung wird.<\/p>\n Wie die Umstellung bei den beiden Strategien gehandhabt wird, h\u00e4ngt vom gew\u00fcnschten Ergebnis ab. Blue-Green Deployments sollen Ausfallzeiten vermeiden<\/strong>. Canary Deployments werden verwendet, um ein neues Feature in einer Produktionsumgebung mit minimalem Risiko zu testen. Canary Deployments sind gezielter.<\/p>\n F\u00fcr ein Canary Deployment<\/a> sind nur wenige Schritte erforderlich:<\/p>\n Identifizieren Sie Ihre Canary-Gruppe<\/strong><\/p>\n Es gibt verschiedene M\u00f6glichkeiten, wie Sie UserInnen als Canary-Gruppe ausw\u00e4hlen k\u00f6nnen.<\/p>\n Zufallsbedingte Teilgruppe<\/strong><\/p>\n W\u00e4hlen Sie verschiedene UserInnen wirklich nach dem Zufallsprinzip aus, zum Beispiel mit einem Load Balancer. Aber auch eine Flag Management Software kann einen bestimmten Prozentsatz des gesamten Traffics \u00fcber ein einfaches Modulo an einen Canary-Test weiterleiten.<\/strong><\/p>\n Early Adopter<\/strong><\/p>\n Wenn Sie ein Early Adopter-Programm f\u00fcr besonders engagierte UserInnen durchf\u00fchren, nutzen Sie diese als Canary-Gruppe. Machen Sie es zum Vorteil ihres Programms. Als Gegenleistung, die Bugs zu tolerieren, auf die sie bei einem Canary Deployment sto\u00dfen k\u00f6nnten, bieten Sie ihnen Treuepr\u00e4mien an.<\/p>\n Nach Region<\/strong><\/p>\n Vielleicht m\u00f6chten Sie bei Ihrem Canary Deployment auf eine bestimmte Region setzen. Legen Sie zum Beispiel fest, dass Ihr Canary Deployment in den sp\u00e4ten Abendstunden an europ\u00e4ische IPs geleitet wird. So vermeiden Sie, dass UserInnen tags\u00fcber Ihre neuen Features sehen, erhalten aber eine Handvoll UserInnen Sessions nach Feierabend.<\/p>\n Interne Testpersonen<\/strong><\/p>\n Sie k\u00f6nnen jederzeit Sessions aus Ihren internen Subnetzen als Canary Deployment konfigurieren.<\/p>\n Zweck eines Canary Deployments ist, eine klare Antwort mit \u201eJa\u201c oder \u201eNein\u201c auf die Frage zu erhalten, ob Ihr Feature sicher ist, um es in die Produktion zu geben. Um diese Frage zu beantworten, m\u00fcssen Sie zun\u00e4chst entscheiden, welche Kennzahlen Sie verwenden wollen, und dann die Mittel zur \u00dcberwachung der Performance installieren.<\/p>\n Sie k\u00f6nnen zum Beispiel Folgendes \u00fcberwachen:<\/p>\n![\"Canary](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/peter-gombos-8y3e2M6APy4-unsplash-1024x683.jpg\")
Was ist ein Canary Deployment?<\/strong><\/h2>\n
![\"Canary](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/canary.jpg\")
Canary Releases vs. Canary Deployments<\/strong><\/h2>\n
![\"Beispiel](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/canary-release-example.png\")
![\"Beispiel](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/canary-deployment-example-web.jpg\")
Canary Deployment \u2013 Pros und Kontras<\/strong><\/h2>\n
Pros<\/h3>\n
![\"Feature](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/danial-igdery-FCHlYvR5gJI-unsplash-1024x683.jpg\")
Kontras<\/strong><\/h3>\n
![\"Canary](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/canary-release-1.png\")
<\/p>\n![\"Canary](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/canary-release-2.png\")
<\/p>\n![\"Canary](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/canary-release-3.png\")
Wann sollte man auf Canary Deployments verzichten?<\/strong><\/h2>\n
\n
Canary Deployments im Vergleich zu anderen Bereitstellungsstrategien<\/strong><\/h3>\n
![\"Diagramm](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/bluegreen1.png\")
Wie wird ein Canary Deployment durchgef\u00fchrt?<\/strong><\/h2>\n
![\"Diagramm](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/ring-based-deployment-1024x413.png\")
Entscheiden Sie sich f\u00fcr Ihre Canary-Kennzahlen<\/strong><\/h3>\n
![\"Flagship](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/feature_management_performance_kpi.png\")