{"id":112376,"date":"2020-08-05T08:28:23","date_gmt":"2020-08-05T08:28:23","guid":{"rendered":"https:\/\/staging.wingify.com\/blog\/canary-releases\/"},"modified":"2020-08-05T08:28:23","modified_gmt":"2020-08-05T08:28:23","slug":"canary-releases","status":"publish","type":"post","link":"https:\/\/wingify.com\/blog\/de\/canary-releases\/","title":{"rendered":"Canary Releases \u2013 3 entscheidende Fragen, die Sie sich stellen m\u00fcssen, damit Sie einen Launch unbedenklich freigeben k\u00f6nnen"},"content":{"rendered":"

Sie haben die Geschichte schon geh\u00f6rt, oder?<\/p>\n

Kohleabbau war eine gef\u00e4hrliche Arbeit. Jederzeit konnten sich Kohlebergwerke mit t\u00f6dlichen, aber nicht wahrnehmbaren Gasen f\u00fcllen. Also haben sich Bergleute einen ganz einfachen Trick ausgedacht, um am Leben zu bleiben: Sie nahmen einen Kanarienvogel mit nach unten. Die Kanarienv\u00f6gel reagierten auf diese t\u00f6dlichen Gase empfindlicher als Bergleute. W\u00e4ren giftige Gase in die Mine eingedrungen, w\u00e4ren die Kanarienv\u00f6gel als Erste gestorben. Die Bergleute w\u00e4ren somit gewarnt gewesen und h\u00e4tten den Stollen verlassen, bevor ihnen dasselbe Schicksal widerfahren w\u00e4re.<\/p>\n

Softwareentwickler nahmen sich diese Geschichte zu Herzen und entwickelten ihre eigene Methode, Gefahren in ihrer Arbeit aufzudecken, bevor es f\u00fcr ihre Applikation zu sp\u00e4t ist. So entwickelten sie \u201eCanary Releases\u201c \u2013 eine bew\u00e4hrte Methode im Rahmen des Feature Releasemanagements, bei der eine neue Funktion einer kleinen User-Gruppe bereitgestellt wird, um sie in einer Live-Umgebung zu testen. Sollte etwas bei dem neuen Feature vollkommen falsch laufen, w\u00fcrden die Entwickler vom Canary Release gewarnt werden, bevor das Feature f\u00fcr die breite User Base freigeschaltet wird und dann wirklichen Schaden anrichten w\u00fcrde.<\/p>\n

Softwareentwickler sollten nicht ihr eigenes Leben, sondern das \u00dcberleben der Software sch\u00fctzen, die sie entwickelten. Sie waren in der Lage, Probleme zu suchen und zu beheben, in der Realit\u00e4t genutzte Daten zu sammeln, die im Hinblick auf eine bessere Software umgesetzt werden, und allgemein das Risiko besonders kritischer Momente im Lebenszyklus der Softwareentwicklung und des Release zu minimieren.<\/p>\n

F\u00fcr Produktmanager sind Canary Releases mittlerweile zu einem \u201eMust-do\u201c geworden. Selbst ein einziger Bug oder ein falsch ausgerichtetes Feature kann Monate harter Arbeit vernichten, wenn nicht sofort gegengesteuert wird, solange die Probleme noch gering sind und unter Kontrolle gehalten werden k\u00f6nnen.<\/p>\n

Das sind die schlechten Nachrichten. Die gute Nachricht aber ist: Sie k\u00f6nnen diesem potenziellen Krisenszenario mit einem Canary Release vorbeugen, das sogar schnell, einfach und intelligent durchgef\u00fchrt werden kann, wenn Sie sich die folgenden drei wichtigen Fragen stellen.<\/p>\n

Frage 1: <\/b>Welche User kommen f\u00fcr Ihr Canary Release in Frage?<\/h2>\n

Eine entscheidende Frage. Leider gibt es aber nicht die eine \u201erichtige\u201c Antwort. Welche User-Gruppe Sie w\u00e4hlen, h\u00e4ngt konkret von der Art Ihres Canary Release ab und davon, was Sie sich von dem Release erhoffen.<\/p>\n

Generell gibt es hier zwei Denkmodelle:<\/p>\n

    \n
  1. Release f\u00fcr eine \u201ewarme\u201c Zielgruppe.<\/li>\n
  2. Release f\u00fcr eine \u201ekalte\u201c Zielgruppe.<\/li>\n<\/ol>\n

    Nach dem ersten \u201ewarmen\u201c Denkmodell<\/strong>\u00a0m\u00fcssten Sie Ihr Canary Release Erstanwendern bereitstellen, die Ihnen dann eine Fr\u00fchwarnung geben. Prinzipiell kennen Sie diese User und wissen, dass sie Ihnen gegen\u00fcber positiv eingestellt sind und das Produkt sch\u00e4tzen, ja st\u00e4ndig verwenden. Nachdem Sie die User ausgew\u00e4hlt haben, informieren Sie sie im Voraus dar\u00fcber, dass sie einige neue Features erhalten, die noch nicht perfekt sind, sodass sie mit kleinen Problemen rechnen m\u00fcssen.<\/p>\n

    Der Vorteil hier ist simpel \u2013 Sie erhalten Feedback und Daten von Usern, die mit Ihren neuen Features in einer realen Umwelt herumexperimentieren. Allerdings scheuen Sie dabei m\u00f6glichst jedes Risiko.<\/p>\n

    Der Nachteil ist etwas subtiler. Da Sie Ihr Feature f\u00fcr eine \u201ewarme\u201c Zielgruppe freigeben, k\u00f6nnen Sie sich nicht sicher sein, ein zu 100\u00a0% ehrliches Feedback zu erhalten. Und da diese Gruppe oft aus Erstanwendern und Power Usern besteht, ist es auch nicht sicher, dass sie genauso wie normale Durchschnittsnutzer mit den neuen Features herumspielen und technische Probleme umgehen.<\/p>\n

    Nach dem zweiten, dem \u201ekalten\u201c Denkmodell<\/strong> sollten Sie User nach dem Zufallsprinzip ausw\u00e4hlen, die Sie im Voraus benachrichtigen oder nicht, dass sie einige neue, potenziell fehlerhafte Features testen werden.<\/p>\n

    Bei dieser User-Gruppe bestehen deutlich gr\u00f6\u00dfere Risiken, wenn neue Features getestet werden. Allerdings erhalten Sie auch Daten, die vertrauensw\u00fcrdiger, realistischer und nutzbarer nicht sein k\u00f6nnten. Sie werden sehen, wie eine Vielzahl von Usern Ihr Feature nutzt. Sie werden deutlich gr\u00f6\u00dferes, glaubw\u00fcrdiges Feedback generieren (vor allem, wenn etwas nicht richtig funktioniert) und insgesamt werden Sie eine deutlich klarere Vorstellung davon erhalten, was tats\u00e4chlich passiert, wenn Sie heute Ihr neues Feature freischalten w\u00fcrden.<\/p>\n

    Welche User-Gruppe sollten Sie also w\u00e4hlen?<\/p>\n

    In der Praxis werden Sie vermutlich eine User Base w\u00e4hlen, die zwischen diesen beiden Extremen liegt.<\/strong>\u00a0Sie werden wahrscheinlich eine etwas erweiterte Segmentierung und Personalisierung vornehmen, mit denen Ihre neuen Features f\u00fcr eine Zielgruppe freigegeben werden, die f\u00fcr diese getesteten Features besonders relevant und geeignet ist, aber auch hinreichend untergliedert ist, damit Sie nicht Gefahr laufen, unter dem Strich Ihrem Produkt dauerhaft zu schaden, sollte das Release schlecht sein.<\/p>\n

    Genau genommen k\u00f6nnen Sie sich mit dem richtigen Ansatz an beide Gruppen wenden \u2013 Tests mit mehreren Zielgruppen durchf\u00fchren, die Ihnen jeweils verschiedene Formen von wertvollem Feedback und Daten bieten. Sie k\u00f6nnen sogar mehrere Tests mit mehreren Zielgruppen f\u00fcr mehrere Features deutlich einfacher als zuvor durchf\u00fchren.<\/p>\n

    Hier die Gr\u00fcnde, weshalb.<\/p>\n

    Frage 2: Welche Features werden Sie in Ihrem Canary Release testen?<\/h2>\n

    Diese Frage m\u00fcsste sich einfach beantworten lassen. Sie konnten ein Canary Release eigentlich nur f\u00fcr eine relativ begrenzte Anzahl von Feature-Tests bereitstellen. Aber in den letzten Jahren sind Ihre M\u00f6glichkeiten regelrecht explodiert. Hier, was sich ge\u00e4ndert hat.<\/p>\n

    In der Vergangenheit waren f\u00fcr den Launch von Canary Releases relativ viele Ressourcen notwendig. Sie konnten Ihre Codebasis gef\u00e4hrden und Sie viel Zeit, Aufmerksamkeit und M\u00fche kosten. Und sie konnten den Entwicklungsprozess insgesamt drastisch verlangsamen. Immer wenn Sie ein Canary Release durchf\u00fchren wollten, mussten Sie sicherstellen, dass sich dieser Aufwand auch 100\u00a0% lohnt \u2013 und das schr\u00e4nkte die Art von Funktionen, die Sie testen konnten, stark ein.<\/p>\n

    Gr\u00f6\u00dftenteils lohnten sich Canary Releases nur f\u00fcr besonders sichtbare High-Touch-Funktionen, die f\u00fcr die Applikation grundlegend waren, d.\u00a0h. Dinge wie die umfassende \u00dcberarbeitung einer ganzen Funktionsreihe oder funktionaler Eckpunkte Ihrer Anwendung. Im Gro\u00dfen und Ganzen lohnte es sich nicht, Ressourcen im Rahmen eines Canary Release f\u00fcr den Test einer einzigen, kleinen, isolierten Funktion einzusetzen.<\/p>\n

    Dadurch waren Ihre M\u00f6glichkeiten begrenzt und Sie konnten nicht schnell, agil und reaktiv vorgehen. Sie mussten abwarten, bis gen\u00fcgend Funktionen bereitgestellt wurden, bevor Sie auch nur eine von ihnen testen konnten. Sie konnten nach einem Feedback oder nach dem Erhalt von Daten aus Ihrem Release nicht jede Funktion auf die Schnelle erneut in Angriff nehmen. Kurz gesagt \u2013 Ihr Canary Release war nicht besonders\u00a0agil<\/em>.<\/p>\n

    Aber heute sind Sie mit dem richtigen Ansatz deutlich flexibler, wenn Sie entscheiden m\u00fcssen, welche Funktionen w\u00e4hrend Ihres Canary Release getestet werden sollen. Jetzt k\u00f6nnen Sie eine einzige, kleine, isolierte Funktion testen, sobald sie bereitgestellt werden kann \u2013 in einer realen Umgebung, ohne substanziellen Mehraufwand f\u00fcr Ihr Team.<\/p>\n

    Und so wird\u2018s gemacht<\/p>\n

    Frage 3: Wie f\u00fchren Sie Ihr Canary Release faktisch durch?<\/h2>\n

    Canary Releases waren derart ressourcenintensiv, weil alle damit verbundenen Vorgehensweisen mehr oder weniger manuell verliefen.<\/p>\n

    Sie mussten einen Weg finden, die aktualisierte Version Ihrer Applikation nur bestimmten Usern bereitzustellen. Sie mussten sowohl kurz- als auch langfristige \u00c4nderungen an Ihrem Code vornehmen, konfigurieren und \u00fcberwachen. Sie mussten jede einzelne User-Gruppe im Rahmen verschiedener Tests manuell verfolgen und die Nutzung, das Feedback und jeden KPI dokumentieren, der von den Tests direkt betroffen war. Und all dies mussten Sie abwickeln, w\u00e4hrend die Funktionen der Standardversion Ihrer Anwendung perfekt aufrecht gehalten werden mussten.<\/p>\n

    F\u00fcr den gesamten Prozess waren viele Stunden notwendig. Ein fehlertr\u00e4chtiger Prozess. Und es war nicht m\u00f6glich, schnelle, komplexe Tests durchzuf\u00fchren, auch nicht mit den besten Teams an Ihrer Seite.<\/p>\n

    Was hat sich also ge\u00e4ndert?<\/p>\n

    Mit einem Wort: die Software.<\/p>\n

    Jetzt k\u00f6nnen Sie viele Prozesse im Rahmen eines Canary-Tests und jedes Experiment mit einem einzigen Dashboard auf einer einzigen zentralen Plattform durchf\u00fchren.<\/p>\n

    Mit der richtigen Plattform k\u00f6nnen Sie:<\/p>\n