Dominik Brauch führt dich durch praxisnahe Use Cases und zeigt dir konkrete Ansätze, um jede Phase der Customer Journey zu verbessern – von der ersten Interaktion bis hin zur langfristigen Kundenbindung. Lerne, wie du durch smarte Strategien und optimierte Customer Journeys den wachsenden Anforderungen gerecht wirst und einen spürbaren Business Impact erzielst.

Was bedeutet CX Shot? Der CX Shot ist unser neues Webinar-Format, das in nur 15 Minuten eine konkrete Fragestellung behandelt, gefolgt von 5 Minuten Fragerunde mit unserem Speaker. So wird die Wissensvermittlung schnell und prägnant – eben wie ein Shot!

Der Beitrag CX Shot #5: Wie lässt sich durch gezielte Optimierung der digitalen Customer Journey langfristiger Erfolg erzielen? erschien zuerst auf abtasty.

Code Freezes mögen heutzutage wie ein veraltetes Konzept erscheinen, ein Überbleibsel aus der Zeit, als starre Wasserfallmodelle die einzige Option für die Produktentwicklung und Releases waren.

Das ganze Konzept, die Produktion zu stoppen und Releases zu verzögern, nur um Bugs und andere funktionale Probleme zu testen, hat keinen Platz mehr im modernen agilen Produktmanagement und in DevOps-Praktiken, bei denen der Code in jeder Phase des Entwicklungsprozesses getestet und überprüft wird.

Zumindest scheint dies der allgemeine Konsens in vielen technischen Teams zu sein.

Aber ist das wirklich so? Wenn man erstmal an der Oberfläche der häufigsten Argumente gegen die Integration von Code Freezes in das agile Produktmanagement kratzt, erscheinen sie dann immer noch veraltet?

In diesem Artikel gehen wir auf die drei Hauptargumente ein, die gegen die Integration von Code Freezes in dein agiles Produktmanagement sprechen, und wir zeigen auf, wo diese Argumente nicht zutreffen, um dir zu helfen, eine bessere Entscheidung zu treffen, ob du Code Freezes in die Arbeitsabläufe deines Unternehmens integrieren solltest oder nicht.

Was ist ein Code Freeze?

Beginnen wir zunächst damit, was ein Code Freeze eigentlich ist, um zu verstehen, ob es in der modernen Softwareentwicklung noch einen Platz hat.

Ein Code Freeze ist eine traditionelle Praxis unter Entwicklern, die Änderungen oder die Veröffentlichung neuen Codes zu stoppen, um die Stabilität der Website oder App während eines bestimmten Zeitraums zu gewährleisten. Ein Code Freeze wird in der Regel in Zeiten implementiert, in denen ein höherer Traffic als normal erwartet wird, insbesondere bei E-Commerce-Websites in der Peak Season.

Was bedeutet das? In traffic-starken Zeiten im E-Commerce unterlässt du vorübergehend sämtliche Änderungen an der Website. Jegliche Änderungen mit Auswirkung auf die User Experience während der Peak Season können letztlich zu einem Verlust an Conversions und Gewinn führen.

Mit anderen Worten: Ein Code Freeze wird durchgeführt, um sich vor möglichen Fehlern zu schützen, die durch die zusätzliche Belastung der Website entstehen.

Betrachten wir ein praktisches Beispiel: Die Entwickler beschließen, eine neue Code-Änderung während des „Black Friday“ einzuführen, an dem der Traffic besonders hoch ist, da die Kunden auf der Suche nach den besten Angeboten sind. Es stellt sich jedoch heraus, dass es einen Fehler gibt, mit dem sie nicht gerechnet hatten. Während die Entwickler versuchen, das Problem zu beheben, kommt es zu Ausfallzeiten auf der Website, was zu Umsatzeinbußen führen kann, da die Kunden ihre Einkäufe nicht abschließen können.

Um dieses Worst-Case-Szenario zu vermeiden, verhängen die Entwickler stattdessen eine Code-Freeze-Zeit, in der keine weiteren Code-Änderungen vorgenommen werden. Auf diese Weise wird sichergestellt, dass eine Website bis zum Ende der Zeit mit hohem Traffic-Aufkommen ohne Probleme funktioniert.

Was beinhaltet eine agile Methodik?

Im Folgenden werden wir die Idee hinter dem agilen Konzept erörtern, um besser beurteilen zu können, ob es mit Code Freezes vereinbar ist, bevor wir die häufigsten Argumente gegen diese Methode untersuchen.

Die agile Methodik zielt darauf ab, Projekte in regelmäßig wiederkehrende Zyklen, sogenannte Sprints, aufzuteilen, und wird weitgehend durch das Feedback der Kunden bestimmt. Dies hilft den Teams, den Verbrauchern schnell einen größeren Wert zu liefern.

Mit anderen Worten: Diese Methodik fördert die kontinuierliche Iteration und Verbesserung von Produkten und Tests während des gesamten Software Development Life Cycles.

Durch die Aufteilung der Entwicklung in Sprints wird die Zykluszeit verkürzt, was die Markteinführung beschleunigt und es den Teams ermöglicht, schneller auf Marktanforderungen zu reagieren.

Vor diesem Hintergrund kann ein Code Freeze die Fähigkeit von Teams, schnell einen Mehrwert zu liefern, potenziell einschränken, da sie eine Freeze-Phase festlegen.

Als Nächstes werden wir uns einige der gängigen Argumente gegen Code Freezes im Kontext einer agilen Methodik ansehen.

Argument 1: Code Freezes sind irrelevant und unnötig

Dieses Argument ist ziemlich simpel und konkret – aufgrund moderner Agile Methodiken und Tools sind spezielle QAs und Testzeitfenster nicht mehr notwendig.

Agile Methoden wie Peer Code Reviews, Pair Programming und die ständige Überwachung des Systemzustands geben dir einen viel besseren Einblick in die Leistung einer Anwendung oder eines Features, während diese entwickelt werden. Fehler und Probleme lassen sich leichter und mit größerer Wahrscheinlichkeit bereits während der Entwicklung erkennen und beheben, bevor spezielle Tests und QA-Aktivitäten durchgeführt werden.

Je ausgefeilter dein agiler Ansatz ist, desto mehr wirst du versuchen, dieses Zeitfenster zu verkleinern. Die derzeit raffiniertesten Agile-Ansätze sind Continuous Integration und Continuous Deployment (CI/CD).

Diese Prozesse zielen darauf ab, die Entwicklung in kleine, inkrementelle Änderungen aufzuteilen, um Änderungen am Code so schnell wie möglich „freizugeben“. Bei der reinsten Anwendung von CI/CD existieren Entwicklung und Release kaum noch als getrennte Phasen – neuer Code wird fast unmittelbar nach seiner Fertigstellung in die Anwendung integriert.

Neue Tools haben auch viele Tests automatisiert. Sie evaluieren permanent den Code, um sicherzustellen, dass er fehlerfrei und jederzeit produktionsfähig ist. Probleme werden in Echtzeit erkannt, und es werden sofort Warnmeldungen zu ihrer Behebung verschickt, so dass weniger manuelle Tests durchgeführt werden müssen.

Das Ergebnis dieser neuen agilen Methoden und Tools liegt klar auf der Hand. Die meisten der wichtigsten Test- und QA-Aktivitäten, die während eines Code Freeze durchgeführt werden, werden entweder während der Entwicklung oder von einer Software durchgeführt.

Bei Agile verlassen Software und Funktionen die Entwicklung jetzt mit einem deutlich höheren Maß an Vertrauen als zuvor, wodurch ein dedizierter Code Freeze immer schwerer zu rechtfertigen ist.

Argument 2: Code-Freezes brechen ein zentrales agiles Prinzip

Das zweite Argument ist ein wenig übergeordneter Natur. Es besagt, dass Code Freezes in der agilen Methodik nichts zu suchen haben, weil sie gegen eines der Grundprinzipien dieser Methodik verstoßen – die Verkürzung der Zeit zwischen Entwicklung und Release.

Im Gegensatz dazu musst du getrennte Entwicklungs- und Release-Phasen beibehalten, wenn du Code Freezes einsetzen willst. Schließlich befindet sich der Code Freeze genau zwischen diesen beiden Phasen.

Anstatt zu versuchen, das Zeitfenster zwischen Entwicklung und Release zu minimieren oder zu eliminieren, wie es bei den meisten agilen Methoden der Fall ist, zwingen Code Freezes dich dazu, dieses Zeitfenster so zu formalisieren, dass du deine Zeitpläne für Entwicklung und Release „drum herum“ erstellen musst.

Wenn Code Freezes nicht mit den Grundprinzipien der agilen Methodik übereinstimmen, dann ist es schwer zu argumentieren, sich methodisch weiter an sie zu halten.

Argument 3: Code Freezes führen zu langsameren Releases minderer Qualität

Dieses letzte Argument ist wichtig und sollte unter verschiedenen Blickwinkeln betrachtet werden.

Erstens wird behauptet, dass Code Freezes die Roadmap komplexer machen und die Wahrscheinlichkeit erhöhen, dass etwas schief geht und der Zeitplan durcheinander gerät.

Selbst wenn nichts schief geht, ist die Arbeit, die mit Code Freezes verbunden ist, zeitintensiv und unvorhersehbar (da man nicht weiß, welche Bugs man finden wird und wie lange es dauern wird, sie zu beheben), so dass die bloße Aufnahme von Code Freezes in die Roadmap zu langsameren Entwicklungs- und Release-Zyklen führt.

Einerseits werden die Entwickler während eines Code Freeze weiterhin Code entwickeln, ohne ihn jedoch zu integrieren oder zu testen, während sie darauf warten, dass der Freeze vorbei ist. Dies führt zu einer Anhäufung von Code und damit zu größeren Risiken und Instabilitäten, was die Dynamik deiner CI/CD-Prozesse erheblich verlangsamen könnte. 

Andererseits möchten die Entwickler vielleicht neue Code-Änderungen herausbringen, bevor der Code Freeze beginnt. Dies kann zu unvollständigem oder schlecht geschriebenem Code führen, der aus Zeitgründen nicht den üblichen gründlichen Tests unterzogen wird, da sie sich beeilen, ihre Projekte vor dem Code Freeze abzuschließen. Das Ergebnis ist eine minderwertige, weniger umfangreiche Software und Anwendung.

Außerdem können Code Freezes die Produktivität deines Entwicklungsteams reduzieren. Während agile Methodiken im Allgemeinen und CI/CD im Besonderen dafür sorgen, dass die Entwickler permanent in einer ungebrochenen Produktionskette arbeiten, zwingen Code Freezes deine Entwickler dazu, die Arbeit in vordefinierten Abständen zu unterbrechen.

Mit anderen Worten: Es könnte deine CI/CD-Pipeline unterbrechen.

Dadurch unterbrichst du den Arbeitsrhythmus deines Teams und zwingst es, deine Code-Freeze-Richtlinien zu umgehen, anstatt den Arbeitsfluss zu suchen und aufrechtzuerhalten, der die größte Produktivität verspricht.

Sich für Code Freezes einsetzen: Ein aussichtsloser Kampf?

An dieser Stelle sieht es für jeden düster aus, der Code Freezes immer noch in die agile Methodik integrieren möchte. Es gibt einige sehr überzeugende Argumente und ein insgesamt solides Argument dafür, dass Code Freezes seit der Entwicklung der modernen agilen Methodik zu etwas anderem geworden sind:

1. Obsolet und irrelevant
2. Nicht mit modernen Entwicklungspraktiken übereinstimmend
3. Ein Hindernis für schnelle, qualitativ hochwertige Releases

Diese Argumente sind zwar überzeugend und enthalten viele zutreffende Informationen, aber sie sind nicht unerschütterlich. Und jedes dieser Argumente weist grundlegende Mängel auf, die diskutiert werden müssen, ehe das Kapitel über Code Freezes als nützliche Komponente des agilen Produktmanagements geschlossen werden kann.

Das Problem mit Argument 1: Automatisierte Tests sind nicht umfassend

Automatisierte QA und agile Entwicklungspraktiken haben die Qualität des Quellcodes verbessert, das ist eine Tatsache. Doch nur weil ein Stück Code die Unit-Tests bestanden hat, heißt das noch lange nicht, dass es tatsächlich produktionsreif ist.

Selbst die ausgefeiltesten CI/CD-Ansätze umfassen nicht immer entscheidende Schritte wie Regressionstests, die sicherstellen, dass ein Code-Teil fehlerfrei ist. Letzten Endes gibt es einfach einige Dinge, die man nicht testen und beheben kann, während ein Code-Teil in Produktion ist.

Wenn du dich für die Verwendung von Code Freezes entscheidest, musst du nicht auf die Vorteile der automatisierten QA und der bewährten agilen Verfahren verzichten.

Du und dein Team werden während der Produktion einfach die kleineren, trivialeren Probleme des Codes erkennen, um die Lage zu sondieren und sich auf größere Probleme mit größeren Auswirkungen während des Freeze zu konzentrieren wie zum Beispiel die Gesamtstabilität und -zuverlässigkeit der neuen Software oder Funktion.

Das Problem mit Argument 2: „Reduzieren“, nicht „eliminieren“

Agile ist zwar darauf ausgelegt, die Zeit zwischen Entwicklung und Release zu verkürzen, aber es besteht ein großer Unterschied zwischen dem Versuch, dieses Zeitfenster zu verkürzen, und dem Versuch, es vollständig zu eliminieren. Dies wäre vor allem bei größeren Projekten nahezu unmöglich.

Der Code Freeze kann bei CI/CD sehr kurz sein – oder nur für eine bestimmte Branche gelten, während die Entwicklung in anderen Branchen fortgeführt wird -, aber es existiert trotzdem.

Unabhängig davon, wie ausgefeilt Agile geworden ist, wird es fast immer einen Punkt in allen Roadmaps für Entwicklung und Releases geben, an dem ein neues Softwareteil oder ein neues Feature in einem festen Zustand evaluiert wird, bevor es an die User in der realen Welt geht.

Das Problem mit Argument 3: Geschwindigkeit und Qualität überdenken

Wenn du Code Freezes verwendest, wird die Entwicklung und dein Release-Zyklus um einen neuen Schritt erweitert, und jedes Mal, wenn du einem Prozess einen neuen Schritt hinzufügst, verlangsamst du diesen Prozess und schaffst eine neue potenzielle Schwachstelle. Code Freezes sind da keine Ausnahme.

Aber es ist wichtig, einen Schritt zurückzutreten und diese „Verlangsamung“ und den Produktivitätsverlust aus einem breiteren Blickwinkel zu betrachten.

Wenn deine Funktion Fehler aufweist, musst du diese beheben, unabhängig davon, ob du diese Fehler während eines Code Freeze entdeckt hast oder ob sie erst nach dem Release bekannt wurden. Aus der reinen Entwicklungsperspektive betrachtet, ist der Zeitaufwand für die Fehlerbehebung in beiden Szenarien in etwa gleich.

Wenn du jedoch mit Fehlern in einer Live-Umgebung zu tun hast, musst du dich für eine ganze Reihe anderer Probleme Zeit nehmen, darunter:

• Die Entscheidung, ob du die fehlerhafte Funktion zurücknimmst oder sie in Betrieb lassen sollst.
• Deine Entwickler von ihren neuen Projekten abziehen, nachdem sie mit der Arbeit begonnen haben.
• Die Wiedergutmachung gegenüber den Nutzern, die von den Fehlern betroffen waren.
• Die Beantwortung von Fragen und der Umgang mit internen Stakeholdern, die über die fehlerhafte Version nicht sehr glücklich sind.

Die Liste ließe sich weiter fortsetzen. Es gibt nichts Komplizierteres, Zeitaufwändigeres und Produktivitätsschädigenderes – für dich und dein Team – als die Veröffentlichung eines fehlerhaften Features oder Produkts. Code Freezes minimieren die Wahrscheinlichkeit, dass dies geschieht.

Und was das Argument angeht, dass Code Freezes zu qualitativ minderwertigen Funktionen und Produkten führen, weil sie die Menge der Geschäftsanforderungen reduzieren, die du sammeln kannst?

Deine geschäftlichen Anforderungen werden immer nur eine „beste Spekulation“ darüber sein, wie dein Produkt oder dein Feature funktionieren sollte. Die wertvollsten Ansprüche werden immer von Usern in der realen Welt gestellt, wenn dein Produkt oder dein Feature in echten Szenarien eingesetzt wird.

Wie Feature Flags Code Freezes ersetzen können

Wie wir bereits erwähnt haben, wird ein Code Freeze als Präventivmaßnahme gegen riskante und/oder fehlerhafte neue Code-Änderungen in sensiblen Phasen durchgeführt. 

Ein Code Freeze könnte jedoch das Risiko sogar erhöhen. Da die Entwickler weiterhin an neuen Änderungen arbeiten, die während des Code-Freeze-Zeitraums nicht freigegeben werden, bedeutet dies, dass sich in der nächsten Version eine Reihe von Commits ansammeln wird, was diese Version unglaublich riskant macht. 

Wenn irgendwelche Probleme auftauchen, wird es viel schwieriger sein, die Quelle des Problems zu lokalisieren, was bedeutet, dass mehr Zeit damit verschwendet wird, es zu finden und zu beheben.

An dieser Stelle kommen Feature Flags ins Spiel. Durch die Verwendung von Feature Flags sind die Entwickler nicht mehr auf Code Freezes während Zeiten mit hohem Traffic angewiesen, um das Risiko von Code-Änderungen zu verringern. 

Durch die Entkopplung von Bereitstellung und Release ermöglichen es Feature Flags den Entwicklern, eine neue Funktion oder eine Code-Änderung in die Produktion zu überführen und sie für die Benutzer unsichtbar zu machen, um sie dann nach und nach für bestimmte Benutzergruppen freizugeben – zum Beispiel intern in deinem Unternehmen.

Auf diese Weise können Teams kontinuierlich neuen Code bereitstellen und an neuen Funktionen arbeiten, ohne dass die Kunden davon etwas mitbekommen, da sie hinter diesen Flags versteckt sind und jederzeit ein- oder ausgeschaltet werden können. Teams können eine fehlerhafte Änderung auch jederzeit mit einem Kill Switch ausschalten oder zurücknehmen, so dass die Benutzer während der Korrektur keinen Zugriff mehr darauf haben.

Zusammenfassend lässt sich sagen, dass Feature Flags den Teams mehr Kontrolle über den Release-Prozess geben und dazu beitragen, das Risiko der Bereitstellung in der Produktion zu verringern, insbesondere in besonders sensiblen Zeiten mit hohem Traffic, ohne die Benutzererfahrung negativ zu beeinflussen. 

Ist es an der Zeit, den Code Freeze abzuschaffen?

Letztendlich spielen Code Freezes immer noch eine wichtige Rolle, um Ausfallzeiten oder unerwartete Fehler in besonders geschäftigen Zeiten zu vermeiden.

Da jede E-Commerce-Website anders ist, musst du entscheiden, ob ein Code Freeze die richtige Wahl für deine Website ist. Wenn du dich für einen Code Freeze entscheidest, solltest du gemeinsam mit deinem Entwicklungsteam im Voraus einen detaillierten Plan aufstellen. 

So kannst du feststellen, welcher Code „eingefroren“ werden muss, welcher optimiert werden muss und welche Projekte auf Eis gelegt werden sollten, um „unsaubere“ Releases zu vermeiden, bevor du mit dem Freeze beginnst.

Es gibt Fälle, in denen sie eine weniger kritische Rolle spielen. Bei sehr kleinen Projekten sind beispielsweise keine speziellen Code-Freeze-Zeiten erforderlich.

Bei neuen Features, die relativ geringe Auswirkungen haben, lohnt sich vermutlich kein Freeze. Dasselbe gilt für Release-Pläne, die schrittweise erfolgen, wenn du neue Features nur mit einer warmen Zielgruppe testen willst, die du darauf vorbereitet hast, ein fehlerhaftes, nicht perfektes Szenario zu erwarten; in diesem Fall sind Feature Flags ein effizienter Weg, diese Funktionen schrittweise einzuführen.

Aber in den meisten Fällen lohnt sich der Zeitaufwand – auch wenn er noch so klein ist – um sicherzustellen, dass deine neuen Funktionen so perfekt sind, wie du es dir vorstellst, bevor du sie in die Hände der Menschen gibst, die am wichtigsten sind: Deine User in der realen Welt.

An dieser Stelle werden Feature Flags zu deinen größten Verbündeten, da sie es dir ermöglichen, ein optimales Kundenerlebnis zu bieten, ohne deine Implementierungen unterbrechen zu müssen.

Denke jedoch daran, dass Feature Flags ein großartiges Hilfsmittel sind, welches das ganze Jahr über und nicht nur in Zeiten hohen Traffics eingesetzt werden sollte, um das Risiko zu minimieren und die Qualität zu maximieren.

Der Beitrag Code Freezes: Sind sie für agile Produktmanager noch relevant? erschien zuerst auf abtasty.

In unserem neuen CX Shot zeigt dir Dominik Brauch, wie du durch effiziente Ressourcennutzung und schnellere Iteration Innovationen vorantreiben kannst. Er taucht mit dir in die Welt der Feature Flags ein und erklärt, wie du mit Flagship und Progressiven Rollouts kontinuierlich neue Features ausliefern kannst. Lerne, wie du den steigenden Anforderungen an Product Teams gerecht wirst und durch Softwareentwicklung einen echten Business Impact generierst.

Der Beitrag CX Shot #4: Wie verbessert Feature Experimentation Websites und was sind die Unterschiede zu Web Experimentation? erschien zuerst auf abtasty.

Das Conversion Rate Optimization Team und die Product Feature Teams bei OUI.sncf haben viele Ideen, wie man diese Szenarien vermeiden und wirklich außergewöhnliche Kundenerlebnisse schaffen kann. Die Frage ist: Welche Ideen sollten sie umsetzen? Welche sollten sie skalieren? Und wie können sie sicher sein, dass eine Idee nicht nach hinten losgeht?

Erfahre in dieser Case Study, wie OUI.sncf mithilfe von A/B-Test die Conversion Rate ihrer mobilen App gesteigert hat und durch die Einführung neuer Funktionen mit Feature Experimentation eine Verringerung des Risikos erreichen konnte.

Der Beitrag OUI.sncf setzt auf AB Tasty für risikofreie Innovation erschien zuerst auf abtasty.

Das Marketing Team von Whitepages hatte sich zum
Ziel gesetzt, die Conversion Rate zu erhöhen und
die Zahl der Mitgliedschaften für das monatliche
Abonnement zu steigern, indem die Struktur der
Preisseite verbessert und den Kunden der Vergleich
erleichtert wird.

Erfahre in dieser Case Study, wie Whitepages die Conversion Rate um 23 % und die Anzahl der monatlichen Mitgliedschaften um 31 % mit AB Tasty‘s Feature Experimentation erhöht hat.

Der Beitrag Whitepages steigert die Anzahl an Abos mit AB Tasty‘s Feature Experimentation erschien zuerst auf abtasty.

Im digitalen Zeitalter können sich Unternehmen nicht mehr nur auf die Optimierung für den Desktop konzentrieren, zumal immer mehr Verbraucher ihre mobilen Geräte nutzen, um Websites zu besuchen und Einkäufe über Apps zu tätigen.

Da es jedoch Millionen von Apps gibt, sind der Wettbewerb und die Ansprüche und Erwartungen der Verbraucher so hoch wie nie zuvor. Das bedeutet, dass deine App in einem überfüllten Markt herausstechen muss.

Es ist wichtig, darauf hinzuweisen, dass die Entwicklung mobiler Apps nicht demselben Prozess folgt wie die einer Website App.

In diesem Artikel gehen wir auf die Herausforderungen beim Mobile App Deployment – also der Bereitstellung und Veröffentlichung von mobilen Apps – ein und erläutern, wie du mithilfe von Feature Flags optimierte Mobile Apps erstellen kannst, die den Bedürfnissen deiner Kunden entsprechen.

Diese Inhalte erwarten dich in diesem Blogartikel:

Die Herausforderungen beim Mobile App Deployment

Der Wert von Feature Flags für die Bereitstellung und Freigabe mobiler Apps

Wie kannst du Feature Flags beim Mobile App Deployment verwenden?

Mobile Feature Flags: Use Cases
Use Case 1: Decathlon
Use Case 2: EDF
Use Case 3: Ornikar

Fazit: Feature Flags – Das ultimative Tool für Mobile App Deployment und bessere mobile Erlebnisse

Die Herausforderungen beim Mobile App Deployment

Mobile Entwicklungsteams sind besonders anfällig für Bugs und lange, langwierige Veröffentlichungszyklen.

Kurz gesagt gibt es zwei Hauptprobleme, wenn es um die Freigabe oder Aktualisierung von Funktionen für mobile Anwendungen geht:

1. Du musst warten, bis die App-Stores die Freigabe erteilen (was einige Zeit dauern und die Veröffentlichung erheblich verzögern kann).
2. Danach musst du warten, bis die Nutzer die Aktualisierung manuell aus dem Store herunterladen (was ebenfalls viel Zeit in Anspruch nehmen kann).

Betrachten wir zum Beispiel folgendes Szenario: Du arbeitest an einem Update für deine mobile App. Du gibst es schließlich frei, um dann festzustellen, dass du einen Fehler übersehen hast, der zum Absturz deiner App führt.

In der Zeit, in der du ein neues Update mit einer Fehlerbehebung veröffentlichst, auf die Veröffentlichung im App Store wartest und darauf wartest, dass die Benutzer das Update herunterladen, riskierst du den Verlust einer beträchtlichen Anzahl von Benutzern.

Entwickler und Techniker von Mobilgeräten sind mit einem solchen Szenario nur allzu vertraut. 

Daher kann es ein mühsamer und langwieriger Prozess sein, bis eine Version genehmigt wird. Nach der Genehmigung muss jede fehlerhafte Version korrigiert werden und den App-Store-Genehmigungsprozess von neuem durchlaufen, was zu weiteren Verzögerungen führt. 

Obwohl sich die Überprüfungszeit in den letzten Jahren verbessert hat, kann es zu weiteren Verzögerungen kommen, wenn deine App nicht den Prüfungsrichtlinien des App Stores entspricht. Dies bedeutet, dass du keine Echtzeit-Updates für die Produktion bereitstellen kannst, wie dies bei Web Apps der Fall ist.

Vereinfacht gesagt, ist der Prozess des Mobile App Deployments nicht so einfach wie die Bereitstellung von Web Apps. 

Im Gegensatz zu Web Apps, die automatisch aktualisiert werden, sobald Besucher auf die Website zugreifen, müssen Benutzer eine Aktualisierung der mobilen App in ihrem Store herunterladen, um die neueste Version zu erhalten.  Da sich die Updates nach dem Überprüfungsprozess stapeln, hast du keine Kontrolle darüber, ob die Nutzer die neuesten Versionen herunterladen. 

Daher kann die Bereitstellung von Updates für mobile Apps im Vergleich zu Web Apps mehr Zeit in Anspruch nehmen. Und in einer Zeit, in der die Kunden immer das Beste verlangen, ist es nicht machbar, sie so lange auf ein Update warten zu lassen, vor allem, wenn es sich um einen Fehler handelt, ganz zu schweigen von der Bereitstellung einer neuen App-Version, sobald der Fehler behoben ist.  

In der modernen Softwareentwicklung, in der eine kontinuierliche Bereitstellung unerlässlich ist, um wettbewerbsfähig zu bleiben und die sich schnell ändernden Anforderungen der Kunden zu erfüllen, müssen die Teams auf eine andere Lösung zurückgreifen, um eine höhere Veröffentlichungsfrequenz zu erreichen.

Bleibe up to date in Sachen Customer Experience Optimization: Melde dich zu unserem Newsletter an. Jetzt anmelden!

Der Wert von Feature Flags für die Bereitstellung und Freigabe mobiler Apps

An dieser Stelle kommen Feature Flags ins Spiel.

Im Gegensatz zu clientseitigen Tests, bei denen sich die Experimente auf Webbrowser konzentrieren, geben Feature Flags den Teams die Möglichkeit, serverseitige Experimente über mehrere Kanäle, einschließlich mobiler Apps, durchzuführen.

Feature Flags ermöglichen es Teams, Funktionen für Benutzer ihrer Wahl zu aktivieren oder zu deaktivieren, um Risiken und negative Auswirkungen zu minimieren.

Das bedeutet, dass du Funktionen aus der Ferne ein- oder ausschalten kannst, ohne den Code erneut in den App-Stores bereitzustellen und auf die Genehmigung zu warten oder darauf warten zu müssen, dass alle Änderungen zur gleichen Zeit fertig sind, um deine eigenen Änderungen zu veröffentlichen. Auf diese Weise kannst du Code bereitstellen, wann immer du willst.

Lies mehr dazu: Was ist Remote-Konfiguration in der App-Entwicklung?

Auf diese Weise kannst du deine App auf der Grundlage des Feedbacks deiner Nutzer kontinuierlich und in Echtzeit aktualisieren, ohne ein Update an den App Store zu senden oder auf dessen Genehmigung zu warten. Außerdem kannst du nach und nach neue Funktionen freigeben, ohne dass die Nutzer ständig ihre App-Version aktualisieren müssen.

Mit Feature Flags können Mobile-Entwickler in der Produktion sicher mit einer vordefinierten Zielgruppe testen und Funktionen mit einem Kill Switch deaktivieren, falls Probleme auftauchen. Die Entwickler können dann daran arbeiten, das Problem zu lokalisieren und zu beheben, bevor sie die Funktion für alle Benutzer freigeben.

Wie kannst du Feature Flags beim Mobile App Deployment verwenden?

Feature Flags können nicht nur von Entwicklern, sondern auch von Produkt- und Release-Managern verwendet werden, um das mobile Erlebnis auf verschiedene Weise zu optimieren.

Hier sind einige Beispiele für den Einsatz von Feature Flags in mobilen Anwendungen:

• A/B-Testing: Mit Feature Flags kannst du deine Nutzer in Untergruppen aufteilen, wobei jede Gruppe von Nutzern eine andere Variante der Funktion erhält. Auf diese Weise kannst du testen und feststellen, welche Variante am besten abschneidet und an alle Benutzer verteilt werden sollte. Einfach ausgedrückt: A/B-Tests ermöglichen dir, wertvolles Live Feedback von deinen Nutzern zu sammeln, so dass du fundierte Entscheidungen über die Optimierung deiner Funktionen und Produkte treffen kannst.
• Gezielte Rollouts: Teams können Feature Flags verwenden, um ihre Ideen zu testen, indem sie ihre Funktion schrittweise einführen und nur einer begrenzten Anzahl von Nutzern einen “Early Access” zur App gewähren, z. B. durch Betatests. Auf diese Weise kannst du die Begeisterung für die neue Funktion wecken und die Auswirkungen auf diese ausgewählten Nutzer überwachen. Gezielte Rollouts ermöglichen es den Teams, fundiertere Entscheidungen darüber zu treffen, was zu optimieren ist, und die App auf der Grundlage des Live-Nutzerfeedbacks fein abzustimmen.
• Personalisierung: Feature Flags sind eine großartige Möglichkeit, das Erlebnis für verschiedene Arten von Nutzern zu personalisieren, anstatt ein einheitliches Erlebnis für alle Nutzer zu bieten. Indem du die Funktionen änderst, die bestimmte Benutzer erhalten, kannst du das Benutzererlebnis in mobilen Apps auf einzelne Benutzer oder Benutzersegmente abstimmen. So kannst du z. B. je nach Land, in dem sich der Nutzer aufhält, ein einzigartiges Erlebnis bieten.
• Rollback/Kill Switch: Das wirklich Einzigartige an Feature Flags ist, dass sie Teams in die Lage versetzen, fehlerhafte Updates schnell wieder rückgängig zu machen. Durch einfaches Deaktivieren des entsprechenden Feature Flags kannst du einen Fehler beheben, ohne den langwierigen App-Store-Review-Prozess zu durchlaufen.

Mobile Feature Flags: Use Cases

Wir haben bisher vor allem darüber gesprochen, wie Feature Flags beim Mobile App Deployment eingesetzt werden können. Sie sind aber auch eine großartige Möglichkeit, das Risiko bei der Bereitstellung und beim Testen mobiler Websites zu verringern, insbesondere wenn es um tiefgreifende Änderungen geht, die mit der Backend-Architektur verbunden sind, wie z. B. das Testen neuer Zahlungsmethoden.

Dies lässt sich mit einer Feature-Flagging-Plattform leicht bewerkstelligen, auf der Teams mit einer benutzerfreundlichen Plattform, die von allen Teams genutzt werden kann, regelmäßige Releases sicher bereitstellen können. 

Nehmen wir zum Beispiel an, du hast zwei Zahlungsfunktionen entwickelt: eine für den Desktop und eine für das Handy. Bevor du ein vollständiges Release veröffentlichst, möchtest du sie mit einer kleinen Gruppe von Early Adopters testen, um die Auswirkungen zu überwachen und die Nutzungsrate zu bestimmen.

Mit AB Tasty kannst du ganz einfach einen Anwendungsfall für das Umschalten von Funktionen in deinem AB Tasty Konto erstellen und den KPI auswählen, den du beobachten möchtest, in diesem Fall wären das die Klicks auf den Button „Zur Kasse gehen“ und dann „Conversion Rate“ als Unter-KPI.

Anschließend kannst du zwei Szenarien definieren: eines zur Aktivierung der Funktion auf dem Desktop und ein anderes zur Aktivierung auf mobilen Geräten. Du konfigurierst dann das Flag, das die neue Zahlungsmethode für jedes Szenario aktiviert, wie im Bild unten bei „Scenario mobile“ auf dem Dashboard zu sehen ist.

Mit AB Tasty kannst du ein Szenario speziell für mobile Geräte definieren. (Quelle: Screenshot von der AB Tasty Plattform für Feature Experimentation & Rollouts)

Als Nächstes sehen wir uns Beispiele aus der Praxis an, wie AB Tasty Kunden Feature Flags für mobile Tests verwenden:

Use Case 1: Decathlon

Decathlon, ein französischer Sportartikelhändler mit mehr als 2.000 Filialen in 56 Ländern, wollte die Platzierung von CTAs testen, um deren Wirkung auf allen Geräten, einschließlich Mobilgeräten, und Produktübersichtsseiten, auch Product Listing Pages (PLPs), mit Hilfe von Feature Flags zu messen.

In der ursprünglichen Version, die unten zu sehen ist, wollte das Team von Decathlon APAC eine frühere Platzierung des „In den Warenkorb“-Buttons auf Mobilgeräten auf der Hauptseite unterhalb des Produktbildes testen, um einen positiven Rollout zu gewährleisten und den Uplift zu messen. In der ursprünglichen Version mussten die Nutzer erst auf das Produkt klicken, um zur Produktdetailseite zu gelangen, bevor sie diesen Button sehen konnten.

Decathlon testete für die mobile Version das Hinzufügen eines Warenkorb-Buttons direkt auf der Produktübersichtsseite. (Quelle: Screenshots von Decathlon)

Mit der zuverlässigen Lösung von AB Tasty war das Team in der Lage, die Auswirkungen dieser neuen Funktion auf die Conversions zu testen. Die Änderung der CTA-Platzierung erwies sich als Erfolg und führte zu einem Anstieg der Transaktionsrate um 10,37 % und einem Anstieg des durchschnittlichen Bestellwerts um 11,27 $.

Use Case 2: EDF

EDF (Electricité de France) ist seit über 70 Jahren der größte Stromlieferant in Frankreich. Das Team von EDF wollte die Zahl der Online-Abonnements und -Anrufe über seine App erhöhen.

Insbesondere wollten sie die Auswirkungen einer Änderung des CTA-Designs in der App überwachen. Durch die Verwendung von Feature Flags zur Erhöhung der Sichtbarkeit der CTAs konnte das Team die Auswirkungen auf die Klicks für Online-Abonnements bzw. -Anrufe bei EDF-Beratern messen (und steigern).

Das Team führte einen A/B-Test durch, bei dem der CTA für das Abonnement vor einem orangefarbenen Hintergrund und der CTA für den Anruf vor einem grünen Hintergrund angezeigt wurde. Sie fügten auch Text hinzu, um die Öffnungszeiten zu kommunizieren.

EDF testete die Auswirkungen einer Änderung des CTA-Designs in seiner App. (Quelle: Screenshots von EDF)

Der Anruf-CTA war derjenige, der positivere Ergebnisse lieferte und es dem Team ermöglichte, mehr qualifizierte Leads zu generieren und die Zahl der Anrufe mit EDF-Beratern zu erhöhen.

Mit einem Anstieg der Anrufe um 20 % konnte das Team dann zuversichtlich eine angepasste Variante in der App entwickeln und einführen, bei welcher der neue Anruf-CTA besser sichtbar war.             

Bleibe up to date in Sachen Customer Experience Optimization: Melde dich zu unserem Newsletter an. Jetzt anmelden!

Use Case 3: Ornikar

Oft sind A/B-Tests eine todsichere Methode, um potenzielle Verzerrungen zu beseitigen, und können ein Unternehmen davor bewahren, in eine Optimierungskampagne zu investieren, die ansonsten viel wertvolle Zeit und Ressourcen in Anspruch nehmen würde.

Das war der Fall bei Ornikar, einer Fahrschulplattform in Frankreich mit mehr als 2,5 Millionen Kunden. Das Team wollte den Startbildschirm seiner App überarbeiten und musste herausfinden, welche Änderungen beibehalten und welche verworfen werden sollten.

Das Team richtete einen A/B-Test auf AB Tasty ein, um das bestehende Karussell mit vier Slides und zwei CTAs (linkes Bild) durch einen neuen Startbildschirm mit den Vorteilen von Ornikar, einer neuen CTA-Anordnung und einem detaillierteren Karussell (rechtes Bild) zu ersetzen.

Ornikar testete eine neue Variante des Startbildschirms seiner App. (Quelle: Screenshots von Ornikar)

Der Test wurde über einen Zeitraum von drei Wochen durchgeführt. Nach einer Woche stellte das Team fest, dass die neue Variante nicht so gut funktionierte wie erwartet. Daher pausierte das Team den Test, passte den CTA an und führte den Test erneut zwei Wochen lang durch.

Die Ergebnisse waren nach zwei Wochen immer noch negativ und das Team beschloss, den neuen Startbildschirm nicht in Betrieb zu nehmen.

Dank der Flexibilität der AB Tasty Plattform war das Team in der Lage, innerhalb eines kurzen Zeitraums schnelle Iterationen vorzunehmen. Vor allem konnte Ornikar den Verlust von Konversionen und die Verschwendung von Zeit und Ressourcen vermeiden und die negativen Auswirkungen minimieren, indem es den neuen Startbildschirm zunächst testete, bevor es ihn für alle seine Nutzer einführte.

Fazit: Feature Flags – Das ultimative Tool für Mobile App Deployment und bessere mobile Erlebnisse

Wie wir gesehen haben, sind Feature Flags ein leistungsfähiges Tool, mit dem Teams in einem Unternehmen mehr Kontrolle über mobile Tests und Veröffentlichungen haben und gleichzeitig Risiken reduzieren können.

Feature Flags unterstützen dich nicht nur beim Mobile App Deployment und geben dir die volle Kontrolle über die Veröffentlichung neuer Funktionen trotz der Genehmigungsprozesse im App und Play Store, sondern ermöglichen es den Teams auch, ihre mobilen Anwendungen zu optimieren und das Benutzererlebnis zu personalisieren. Sie ermöglichen dir auch, Funktionen häufiger zu veröffentlichen und schnelles Feedback von deinen wichtigsten Nutzern zu erhalten.

Angesichts der zunehmenden Nutzung mobiler Geräte und der Millionen von Apps, mit denen du konkurrieren musst, ist es von entscheidender Bedeutung, die bestmögliche Benutzererfahrung auf mobilen Geräten zu bieten. Die Durchführung von Experimenten und die Verwendung progressiver Rollouts mit Feature Flags sind der Schlüssel zur Bereitstellung optimaler und großartiger mobiler Erlebnisse.

Die Verwendung einer Plattform eines Drittanbieters für Feature Flags erleichtert das Ein- und Ausschalten von Funktionen und die Fernkonfiguration deiner Flags direkt von der Benutzeroberfläche aus. Indem du alle deine Feature Flags in einem benutzerfreundlichen Web Dashboard kontrollierst, stellst du sicher, dass du mit den wichtigsten Best Practices Schritt hältst, um erfolgreich zu sein und dich von der Konkurrenz abzuheben.

Der Beitrag Mobile App Deployment: Wie Teams Feature Flags gezielt nutzen können erschien zuerst auf abtasty.

Manchmal kann es zu viel des Guten geben, auch wenn es um Feature Flags geht.

Wir sind uns der vielen Vorteile und des Nutzens von Feature Flags für Produkt- und Entwicklungsteams bewusst, aber sie sind auch mit hohen Kosten verbunden, wenn sie nicht richtig verwaltet werden.

Zu Beginn der Entwicklung von Feature Flags mögen die Dinge noch einfach erscheinen. Sie beginnen vielleicht mit ein paar if/else-Anweisungen, aber je fortgeschrittener Ihre Anwendungsfälle werden, desto komplizierter wird es, alle Flags in Ihrem System zu verwalten.

Da aus einer Flag schnell 50 werden, kann die Anzahl der Flags schließlich so hoch werden, dass du leicht den Überblick über alle Flags verlierst, die du und deine Teams erstellt haben, was zu einer „Feature Flag Hell“ führt. Mit anderen Worten: Feature Flags werden zu einer Form von technischer Schuld.

Es gibt jedoch Möglichkeiten, die technischen Schulden in Schach zu halten, und zwar durch den Einsatz eines effizienten Tools, das dir hilft, den Überblick über alle von dir erstellten Flags zu behalten und sie dann zu entfernen, wenn sie ihren Zweck erfüllt haben. In diesem Sinne ist es wichtig, dass du Feature Flags sorgfältig und strategisch einsetzt.

In diesem E-Book stellen wir dir unsere wichtigsten Best Practices für Feature Flags vor, die du und dein Team kennen sollten, um die Fallstricke von Feature Flags zu vermeiden und stattdessen von deren Vorteilen zu profitieren:

• Plane deine Feature Flags sorgfältig
• Benenne deine Flags konsistent
• Richte eine Zugriffskontrolle ein und verwalte sie
• Begrenze und verdeutliche den Umfang der einzelnen Flags
• Bereinige Flags regelmäßig
• Schaffe eine klare Sichtbarkeit aller Flags
• Verwende ein Feature-Management-Tool

Der Beitrag 7 Best Practices für Feature Flags erschien zuerst auf abtasty.

Dies bedeutet nicht, dass Ihre beliebten Rollout- und Feature-Management-Tools verschwinden. Es bedeutet vielmehr, dass wir ein neues, aufregendes Kapitel für AB Tasty aufschlagen, mit dem Ziel, alle unsere Features an einem Ort und unter einem Namen zur Verfügung zu stellen.

Wir haben die Websites von AB Tasty und Flagship zusammengeführt. Alle Ressourcen und Landing Pages, die zuvor auf der Flagship Website (flagship.io) gehostet wurden, können nun an einem Ort auf der AB Tasty Website (abtasty.com) gefunden werden.

Diese Entwicklung bringt mit sich, dass der Name Flagship nicht mehr weitergeführt wird und somit in den „Ruhestand“ geht. Wir fühlen uns zwar ein wenig nostalgisch gegenüber dem alten Namen, aber das Ziel ist es, den Zugang zu den AB Tasty-Lösungen und -Funktionen zu vereinfachen und sie miteinander zu verbinden, um unser Versprechen einzulösen, Ihre Go-to-Plattform für die Verbesserung und Optimierung der Customer Experience zu sein.

Wenn Sie Fragen dazu haben, was diese Änderung für Sie bedeutet, sind Sie hier genau richtig. Im Folgenden gehen wir auf die Änderungen, hilfreiche Links und Ressourcen sowie einige allgemeine FAQs ein.

Wie immer steht Ihnen unser Team an AB Tasty Magic Makers zur Verfügung, um alle zusätzlichen Fragen zu beantworten, die im Laufe der Zeit auftauchen könnten. Wenn Sie nach dem Lesen dieses Artikels noch weitere Fragen haben, zögern Sie nicht, uns eine E-Mail an contact_de@abtasty.com zu schicken, und wir werden diese Seite bei Bedarf aktualisieren.

Wie hängen AB Tasty und Flagship zusammen?

AB Tasty und Flagship waren schon immer ein und dasselbe Unternehmen, nur mit unterschiedlichen Namen für die serverseitigen und clientseitigen Lösungen.

Die Experimentier-Suite von AB Tasty ermöglicht es Marken, clientseitige A/B-Tests und Personalisierungen durchzuführen, um ein umfassenderes digitales Erlebnis zu bieten und die Konversionen zu steigern.

Flagship by AB Tasty wurde ebenfalls entwickelt, um durch risikofreies Feature-Management, serverseitige Experimente und Personalisierung umfassende Erlebnisse zu bieten, die zu Konversionen führen. Wie gesagt, dasselbe Unternehmen, nur unterschiedliche Ansätze, um Marken dabei zu helfen, ihren KundInnen das beste Erlebnis zu bieten.

Was meinen Sie, wenn Sie von Zusammenführung sprechen? Wird die Flagship-Website für immer verschwinden?

Ja, alles auf der Flagship-Website (flagship.io) ist auf die AB Tasty-Website (abtasty.com) umgezogen. Das bedeutet, dass alle Links zu bestehenden Landing Pages und Ressourcen auf AB Tasty umgeleitet werden, und alle neuen Ressourcen werden von nun an direkt auf AB Tasty veröffentlicht. Sie können ganz einfach auf Ressourcen wie E-Books, Blogs, Leitfäden und mehr zugreifen, indem Sie oben auf den Menüpunkt Ressourcen klicken oder dem Link hier folgen.

Warum führen wir die Websites und Namen von Flagship und AB Tasty zusammen?

Von Anfang an haben wir uns auf das konzentriert, was wir am besten können, nämlich unseren KundInnen die Werkzeuge an die Hand zu geben, die sie brauchen, um ihre Ideen zu validieren und gleichzeitig die Wirkung zu maximieren, das Risiko zu minimieren und die Markteinführung zu beschleunigen.

Marketing- und Technikteams arbeiten heute enger zusammen als je zuvor, um neue Funktionen auf den Markt zu bringen und wettbewerbsfähig zu bleiben. Unser kundenorientierter Ansatz bedeutet, dass wir unsere Funktionen leichter zugänglich machen und Ihnen die Tools zur Verfügung stellen möchten, die Sie für all Ihre Experimente und Personalisierungsanforderungen benötigen. Aus diesem Grund haben wir uns entschlossen, Flagship in die AB Tasty-Website zu integrieren und es als AB Tasty’s Feature Experimentation and Experience Rollouts zu positionieren, anstatt als separate Lösung.

Viele unserer clientseitigen KundInnen sind mittlerweile so weit mit ihren Experimenten, dass sie fortgeschrittene Experimente durchführen und erweiterte Funktionen einführen. Für unsere KundInnen, die bereit sind, mit serverseitigen Experimenten zu beginnen, macht es diese Änderung viel einfacher und schneller, alle Informationen und den Support, den sie für alle unsere Features benötigen, einschließlich unserer serverseitigen Funktionalität, an einem Ort zu finden.

Was geschieht mit all den Ressourcen (Blogbeiträge, Leitfäden, E-Books usw.) auf Flagship.io?

Wie bereits erwähnt, sind die Flagship-Inhalte jetzt migriert und alle Links von Flagship.io sind auf AB Tasty umgeleitet. Von dort aus können alle unsere Ressourcen, von Leitfäden bis hin zu Blogbeiträgen und E-Books zu den Themen Feature Management, Experimente und mehr, auf der AB Tasty-Website gefunden werden.

Sie werden schnell merken, dass Sie hier ganz einfach auf Ihre Lieblingsinhalte zugreifen können, wenn Sie nach den Themen „Rollouts“ und „Feature Experimentation“ filtern (Hinweis: Dies ist aktuell nur auf der englischen Seite möglich, die deutschen Inhalte werden aber zeitnah folgen).

Wie kann ich mich bei meinem Flagship-Konto anmelden? Und wo kann ich auf die Dokumentation und die SDK-Bibliotheken zugreifen?

Sie können auf Ihre Konten zugreifen, indem Sie abtasty.com besuchen und auf den „Login“-Button in der oberen rechten Ecke klicken.

Alle unsere Dokumentationen und SDKs haben die gleichen Links wie bisher. Sie können sie über die folgenden Links aufrufen:

• Dokumentation
• Bibliotheken and SDKs

Wie wird sich die Zusammenführung auf die bestehenden KundInnen von Flagship und AB Tasty und die Unterstützung, die sie erhalten, auswirken?

Alle unsere KundInnen, unabhängig davon, ob sie AB Tasty oder Flagship oder beides nutzen, werden davon nicht betroffen sein. Sie können unsere Plattform weiterhin für all Ihre Bedürfnisse rund um das Experimentieren nutzen, ohne dass sich etwas ändert.

Ebenso können Sie erwarten, dass Sie das gleiche Maß an Unterstützung erhalten und Zugang zu dem gleichen engagierten Team für client- und/oder serverseitige Experimente haben wie bisher.

Wie immer wird Ihr CSM Sie rechtzeitig informieren, wenn es Änderungen an der Plattform gibt.

Wie wird sich die Zusammenführung auf neue KundInnen auswirken? Wo kann ich mich für eine Demo für AB Tasty’s Feature Experimentation und Rollouts anmelden?

Wenn Sie neu sind und AB Tasty’s Feature Experimentation oder Experience Rollouts ausprobieren möchten, klicken Sie auf das Banner unten oder auf den „Demo anfragen“-Button oben rechts auf der Seite, um herauszufinden, wie serverseitige Experimente Ihr Unternehmen positiv beeinflussen können.

Ein ganz besonderes Dankeschön geht an unsere KundInnen und unsere PartnerInnen für die Unterstützung bei dieser spannenden Entwicklung von AB Tasty. Ihr Feedback und Ihre Unterstützung tragen dazu bei, wichtige Änderungen wie diese zu gestalten, und wir sind dankbar dafür.

Haben Sie weitere Fragen zu Flagship und AB Tasty? Schicken Sie uns eine E-Mail an contact_de@abtasty.com und bleiben Sie dran für weitere spannende Updates und Informationen, die in Zukunft kommen werden!

Der Beitrag Neues Kapitel für Flagship: Zusammenführung mit der AB Tasty Website erschien zuerst auf abtasty.

Eine schnelle Auslieferung verkürzt auch die Zeit zwischen Softwareentwicklung und Feedback der UserInnen, ein entscheidender Faktor für Teams, die auf Continuous Integration und Continuous Deployment (CI/CD) setzen.

Vor diesem Hintergrund sollten Sie daran denken, Blue-Green Deployment in Ihr CI/CD Toolkit einzuführen. Mit diesem Prozess lassen sich technische und unternehmerische Risiken von Software-Releases reduzieren.

Bei diesem Modell werden zwei identische Produktionsumgebungen mit der Bezeichnung „Blau“ und „Grün“ parallel ausgeführt. Allerdings ist nur eine der beiden Umgebungen aktiv und erhält die Transaktionen der UserInnen. Die andere Umgebung ist produktionsfähig, aber nicht aktiv.

In diesem Artikel beschäftigen wir uns mit der Frage, wie Blue-Green Deployments funktionieren. Wir gehen näher auf die Pros und Kontras dieses Konzepts für Software-Releases ein. Darüber hinaus erklären wir, wie Blue-Green Deployments im Vergleich mit anderen Deployment-Methoden dastehen, und empfehlen Ihnen einige Best Practices für reibungslose Blue-Green-Deployments.

In diesem Artikel greifen wir folgende Punkte auf:

[toc]

Wie funktionieren Blue-Green Deployments?

Eine der größten Herausforderungen beim Deployment-Prozess ist das Cutover vom Testen auf die Produktion. Es muss schnell und reibungslos erfolgen, um die Ausfallzeit zu minimieren.

Das Blue-Green Deployment löst diese Aufgabe, indem zwei parallele Produktionsumgebungen verwendet werden. Dabei ist immer nur eine der beiden Umgebungen aktiv und erhält die Transaktionen der UserInnen. Im Bild unten ist es die grüne Umgebung. Das blaue – nicht aktive – System ist eine nahezu identische Kopie.

Ihr Team verwendet das blaue, nicht aktive System als Staging-Umgebung für die finale Testrunde, wenn ein neues Feature veröffentlicht werden soll. Sobald die neue Software in der blauen Umgebung problemlos funktioniert, kann Ihr Ops-Team den Datenverkehr auf die blaue Umgebung umleiten und dieses System dann live schalten. Anschließend können Sie das Feature in der grünen – inzwischen nicht aktiven – Umgebung implementieren, damit beide Systeme wieder synchron sind.

Damit wäre eigentlich das Wichtigste zum Blue-Green Deployment gesagt. Sie sind sehr flexibel, was die Strukturierung der parallelen Systeme und den Wechsel auf das jeweils andere System betrifft. Es könnte zum Beispiel sein, dass Sie keine parallelen Datenbanken pflegen möchten. In diesem Fall ändern Sie einfach das Routing und leiten den Datenverkehr auf Web- und App-Server weiter. Bei einem anderen Projekt könnten Sie ein Blue-Green Deployment verwenden, um ein noch nicht getestetes Feature im aktiven System zu veröffentlichen, wobei aber das Feature für A/B User-Tests hinter ein Feature Flag gesetzt wird.

Beispiel für ein Blue-Green Deployment

Angenommen, Sie sind in einem e-Commerce-Nischenunternehmen für ein DevOps-Team zuständig. Sie bieten Outfits und Accessoires an, die auf einem kleinen, jedoch hochwertigen Markt gefragt sind. Auf Ihrer Website können die KundInnen Produkte On-Demand personalisieren und bestellen.

Das Backend Ihrer Website enthält viele Microservices in einigen verschiedenen Containern. Sie haben Microservices für die Bestandsverwaltung, das Auftragsmanagement, Personalisierungs-Apps und ein integriertes soziales Netzwerk zur Unterstützung der Nischencommunity Ihrer KundInnen.

Ihr Team gibt frühzeitig und häufig Releases heraus, weil die anhaltende Beliebtheit Ihrer Website Ihrer Meinung nach dem CI/CD-Modell zu verdanken ist. Weil diese Nischencommunity auf der ganzen Welt verstreut ist, bleibt der Traffic auf Ihrer Website recht stabil. Deshalb ist es immer schwierig, einen relativ ruhigen Zeitpunkt zu finden, um Ihr Produktionssystem zu aktualisieren.

Sobald eines Ihrer Teams erklärt, dass das aktualisierte Customization Interface für den finalen Test in der Produktionsumgebung bereit steht, entscheiden Sie sich für ein Blue-Green Deployment, damit das Interface sofort veröffentlicht werden kann.

Am nächsten Tag entschließt sich Ihr Team vor der Mittagpause, den neuen Customizer bereitzustellen. Ab dieser Entscheidung wird der gesamte Traffic auf das blaue Produktionssystem geleitet. Sie aktualisieren die Software auf dem inaktiven grünen System und bitten die Tester und TesterInnen, eine QA durchzuführen. Weil alles in bester Ordnung zu sein scheint, verwendet Ihr Ops-Team einen Load-Balancer, um die User Sessions von „Blau“ auf „Grün“ zu leiten.

Nachdem der gesamte Traffic auf „Grün“ geleitet wurde, machen Sie diese Umgebung zur offiziellen Produktionsumgebung und setzen „Blau“ auf inaktiv. Ihr Dev-Team pusht den aktualisierten Customizer Code auf „Blau“, bestellt das Mittagessen und wirft einen Blick auf Ihren Backlog.

Pros von Blue-Green Deployments: Vorteile und Use Cases

Ein wesentlicher Vorteil von Blue-Green Deployments gegenüber anderen Strategien für Software-Releases ist ihre Flexibilität. Sie können in verschiedensten Umgebungen und vielen Use Cases nützlich sein.

Schnelle Releases

Für Product Owner, die innerhalb von CI/CD Frameworks arbeiten, sind Blue-Green Deployments eine ausgezeichnete Methode, Ihre Software in Produktion zu nehmen. Software können Sie praktisch zu jedem Zeitpunkt veröffentlichen.  Sie müssen den Release nicht mehr auf ein Wochenende verschieben oder außerhalb der Geschäftszeiten planen: Meistens können Sie die Software einfach durch Umschalten aktiv stellen. Weil mit diesen Deployments keine Ausfallzeiten verbunden sind, haben sie keine negativen Auswirkungen auf die UserInnen.

Sie sind auch für DevOps-Teams weniger disruptiv. Sie müssen Updates nicht mehr überstürzt in einem bestimmten Zeitfenster vornehmen, wodurch sich Deployment-Fehler und unnötiger Stress vermeiden lassen. Auch für Führungsteams hat diese Methode Vorteile. Sie müssen bei einem Ausfall nicht ständig auf die Uhr schauen und sich den Umsatzverlust ausrechnen.

Rollbacks leicht gemacht

Der umgekehrte Prozess kann genauso schnell durchgeführt werden. Weil Blue-Green Deployments zwei parallele Produktionsumgebungen verwenden, können Sie bei einem Problem in Ihrer Liveumgebung schnell auf die stabile Umgebung zurückschalten.

Dadurch lassen sich die Risiken beim Experimentieren während der Produktion reduzieren. Ihr Team kann Probleme durch die Umleitung auf die stabile Produktionsumgebung einfach beheben. Dabei besteht die Gefahr Transaktionen der UserInnen zu verlieren – wir kommen später noch darauf zurück – doch es gibt eine Reihe von Strategien, um mit dieser Situation umzugehen.

Sie können Ihre App während eines Cutover vorübergehend in den Read-Only Modus setzen. Oder Sie können rollierende Cutover mit einem Load-Balancer durchführen, während Sie den Abschluss der Transaktionen in der Liveumgebung abwarten.

Integriertes Disaster Recovery

Weil Blue-Green Deployments zwei Produktionsumgebungen verwenden, bieten sie implizit Disaster Recovery für Ihre Business-Systeme. Eine duale Produktionsumgebung fungiert als eigenes Hot Backup.

Load Balancing

Bei parallelen Blue-Green Produktionsumgebungen lässt sich der Load-Balancer leicht bewerkstelligen. Wenn zwei Umgebungen funktionsmäßig identisch sind, können Sie einen Load-Balancer oder ein Feature Toggle in der Software verwenden, um Traffic nach Bedarf auf verschiedene Umgebungen zu leiten.

Einfacheres A/B Testing

Ein weiterer Use Case für parallele Produktionsumgebungen ist A/B Testing. Sie können neue Features in die inaktive Umgebung laden und den Traffic dann mit einem Feature Toggle zwischen Ihrer blauen und Ihrer grünen Umgebung aufteilen.

Sammeln Sie Daten von diesen geteilten User Sessions, überwachen Sie Ihre KPI und wenn die Analysen der neuen Features in Ihrem Management-System in Ordnung zu sein scheinen, können Sie den Traffic auf die aktualisierte Umgebung umleiten

Kontras von Blue-Green Deployments: Probleme, über die Sie sich im Klaren sein sollten

Blue-Green Deployments bieten viele Vorteile, stellen DevOps-Teams jedoch auch vor große Herausforderungen hinsichtlich Infrastruktur und Praktiken. Bevor Sie Blue-Green Deployments in Ihren CI/CD-Prozess integrieren, sollten Sie diese Probleme verstehen.

Blue-Green Deployments sind ressourcenintensiv

Wie inzwischen klar ist, müssen Sie für ein Blue-Green Deployment Ressourcen für zwei Produktionsumgebungen bereitstellen und beide Umgebungen pflegen. Für einige Unternehmen können die entsprechenden finanziellen Kosten und der Zeitaufwand für den Sysadmin zu hoch sein.
Andere Unternehmen können diese Ressourcen möglicherweise nur für ihre besonders hochwertigen Produkte bereitstellen. Soll das DevOps-Team in diesem Fall Software nur für bestimmte Produkte in einem CI/CD-Modell veröffentlichen? Langfristig ist dies möglicherweise nicht tragbar.

Zusätzlicher Aufwand für die Datenbankverwaltung

Die Verwaltung einer bzw. mehrerer Datenbanken in parallelen Produktionsumgebungen kann kompliziert sein. Sie müssen daran denken, was sie nach einem Software Update brauchen, sowohl in der blauen als auch in der grünen Umgebung, wie zum Beispiel alle externen Services, die Sie aufrufen.
Was passiert zum Beispiel, wenn eine Spalte der Datenbank aufgrund einer Änderung des Features umbenannt werden muss? Sobald Sie den Namen der Spalte in der blauen Umgebung ändern, funktioniert die grüne Umgebung (mit dem alten Code) mit dieser Datenbank nicht mehr.
Kann Ihre gesamte Produktionsumgebung überhaupt mit zwei separaten Datenbanken funktionieren? Meistens nicht, nämlich wenn Sie Ihr Blue-Green System für Load-Balancing, Testing oder irgendeine andere Funktion verwenden, außer als Hot Backup.

Produktmanagement

Abgesehen von der Systemadministration, erfordert das Produktmanagement in zwei nahezu identischen Umgebungen auch mehr Ressourcen. Produktmanager brauchen zuverlässige Tools, um nachzuverfolgen, wie ihre Software performt, welche Services die verschiedenen Teams aktualisieren und wie sie die entsprechenden KPI überwachen können. Weil diese Aktivitäten überwacht und kontrolliert werden müssen, ist ein zuverlässiges Produkt- und Feature-Management Dashboard besonders wichtig.

Blue-Green Deployments und Rolling Deployments

Blue-Green Deployments sind selbstverständlich nicht die einzige Option für schnelle Software-Releases. Ein weiteres beliebtes Konzept ist das Rolling Deployment.

Auch Rolling Deployments benötigen eine Produktionsumgebung, bei der eine Applikation auf mehreren Servern gehostet wird. Oft, aber nicht immer, ist ein Load-Balancer vorgeschaltet, um den Traffic zu verteilen. Wenn das DevOps-Team für ein Update seiner Applikation bereit ist, wird ein gestaffelter Release konfiguriert, wobei die aktualisierte Applikation von einem Server zum nächsten gepusht wird.

Beim Ausrollen des Release läuft die aktualisierte Applikation auf einigen Live-Servern, während auf anderen noch die alte Version läuft. Beim Blue-Green Deployment hingegen ist die aktualisierte Software für alle UserInnen live oder inaktiv.

Wenn UserInnen eine Session mit der Applikation starten, leitet sie der Load-Balancer entweder auf die alte oder auf die neue Version der Applikation weiter. Wenn das Rollout abgeschlossen ist, wird jede eingehende neue User Session auf die aktualisierte Version der Software geleitet. Sollte während des Rollouts ein Fehler auftreten, kann das DevOps-Team die Aktualisierung stoppen und den gesamten Traffic auf die verbleibenden einwandfrei funktionierenden Server umleiten, bis der Fehler behoben ist.

Rolling Deployments sind eine praktikable Option für Unternehmen mit Ressourcen, die für das Hosting einer Produktionsumgebung dieser Größenordnung notwendig sind. Für diese Unternehmen sind sie eine effiziente Methode, um kleine, graduelle Updates zu veröffentlichen – genau wie Sie das bei agilen Entwicklungsmethoden machen würden.

In anderen Use Cases sind Blue-Green Deployments möglicherweise die bessere Wahl. Wenn Sie zum Beispiel ein wichtiges Update vornehmen möchten und die UserInnen keinen Zugriff auf die alte Version haben sollen, ist ein „alles oder nichts“ Konzept wie das Blue-Green Deployment genau richtig.

Angenommen, Ihre Applikation erfordert ein hohes Maß an technischem Support oder Kundensupport. In diesem Fall ist der Support während der Rolling Deployment Windows noch mehr gefordert, weil die Support-Mitarbeiter nicht wissen können, welche Version der Applikation bei einem User oder einer Userin läuft.

Blue-Green Deployments und Canary Releases

Rolling Deployments und Blue-Green Deployments sind nicht die einzigen Release Strategien. Canary Releases stellen eine weitere Möglichkeit dar. Bei einer Canary Release erhält zuerst nur ein Teil aller Produktionsumgebungen ein Software-Update. Doch statt das Deployment auf den Rest auszurollen, bleibt dieser partielle Release für Testzwecke auf den Teilbereich beschränkt. Ein Teil der UserInnen wird dann durch einen Load-Balancer oder ein Feature Flag zur neuen Software weitergeleitet.

Canary Releases sind sinnvoll, wenn Sie von identifizierbaren UserInnen Daten und Feedback zu einer aktualisierten Software erhalten möchten. Canary Releases fügen sich perfekt in umfassendere rollierende Deployments ein: Sie können die aktualisierte Software schrittweise an immer größere Segmente Ihrer User Base ausrollen, bis schließlich alle Produktionsserver aktualisiert sind.

Best Practices für Blue-Green Deployment

Sie haben viele Möglichkeiten, Software schnell zu veröffentlichen. Wenn Sie Blue-Green Deployment als neue Software Release-Strategie in Betracht ziehen, empfehlen wir Ihnen die folgenden Best Practices.

Automatisieren Sie, was automatisierbar ist

Beim Release-Prozess so oft wie möglich auf Scripting und Automatisierung zurückzugreifen, bietet viele Vorteile. Sie führen nicht nur schneller zum Cutover, sondern lassen auch weniger Raum für menschliche Fehler. Ein Entwickler kann nicht versehentlich einen Punkt auf einer Checkliste vergessen, wenn die Liste von einem Script oder einer Management-Plattform abgearbeitet wird. Wenn alles in ein Script gepackt wird, kann jeder das Deployment durchführen, ob Entwickler oder nicht. Sie müssen nicht warten, bis Ihr Systemexperte wieder im Büro ist.

Überwachen Sie Ihre Systeme

Überwachen Sie immer sowohl die blaue als auch die grüne Umgebung. Damit ein Blue-Green Deployment reibungslos verläuft, müssen Sie wissen, was im aktiven und im inaktiven System vor sich geht.

Beide Systeme benötigen wahrscheinlich dasselbe Warnsystem, für das jedoch verschiedene Prioritäten gesetzt werden. Sie möchten zum Beispiel sofort erfahren, wenn in Ihrem Live-System ein Fehler auftritt. Im inaktiven System hingegen reicht es, wenn der betreffende Fehler im Laufe des Arbeitstages behoben wird.

Schreiben Sie rückwärts und vorwärts kompatible Codes

In einigen Fällen können die neue und die alte Version Ihrer Software während eines Cutovers nicht gleichzeitig ausgeführt werden. Angenommen, Sie müssen das Datenbankschema ändern: In diesem Fall wäre es sinnvoll, Ihre Updates so zu strukturieren, dass sowohl das blaue als auch das grüne System über das gesamte Cutover funktionsfähig ist.

Eine Lösung wäre, Ihre Releases in eine Reihe von noch kleineren Release-Paketen aufzuteilen. Nehmen wir an, unser e-Commerce Unternehmen detailliert sein Sortiment und muss seine Datenbank aktualisieren. Um Klarheit zu schaffen, soll das Feld „Hemd“ in „langaermliges_Hemd“ umbenannt werden.

Dieses Update könnte folgendermaßen aufgegliedert werden:

• Veröffentlichung einer Zwischenversion des Codes, die mit einem Flag aktiviert wird und sowohl die Ergebnisse von „Hemd“ als auch von „langaermliges_Hemd“ interpretieren kann.
• Migration der gesamten Datenbank, um das Feld umzubenennen.
• Veröffentlichung der endgültigen Codeversion – oder Umlegen des Feature Flags – damit die Software nur „langaermliges_Hemd“ verwendet.

Führen Sie mehr und kleinere Deployments durch

Kleinere, häufigere Updates haben sich bereits als integraler Bestandteil der agilen Entwicklung und von CI/CD etabliert. Bei Blue-Green Deployments ist diese Vorgehensweise noch wichtiger. Geringere Deployment-Zeiten verkürzen die Feedback-Schleifen, die Informationen für das nächste Release liefern. Dadurch wird jedes inkrementelle Upgrade effektiver und wertvoller für Ihr Unternehmen.

Reorganisieren Sie Ihre Applikationen in Microservices

Diese Methode geht Hand in Hand mit kleineren Deployments. Durch die Restrukturierung des Applikationscodes in Microservices können Sie Updates und Änderungen einfacher verwalten. Verschiedene Features werden so unterteilt, dass sie leichter getrennt aktualisiert werden können.

Verwenden Sie Feature Flags zur weiteren Risikoreduzierung

An sich öffnen Blue-Green Deployments ein einziges, kurzes Risikofenster. Sie aktualisieren alles, alles oder nichts, können aber jederzeit einen Rückzieher machen, falls ein Problem auftritt.

Blue-Green Deployments verursachen mit jedem Cutover aber auch einen ziemlich konstanten Administrationsaufwand. Sie können diesen Mehraufwand zwar durch Automatisierung reduzieren, doch der Prozess bleibt gleich – egal ob Sie nur eine Codezeile oder Ihre gesamte e-Commerce Suite aktualisieren.

AB Tasty Feature Flag Service

Mit Feature Flags lässt sich bis ins Detail kontrollieren, wie und wann UserInnen neu verfügbare Software nutzen können. Feature Flags verhalten sich wie leistungsstarke „If“-Statements, ab denen während der Laufzeit mindestens einem von zwei oder mehreren verschiedenen Codepfaden abhängig von einer gegebenen Bedingung gefolgt wird.

Diese Bedingungen können einfache „Ja/Nein“ Prüfungen oder komplexe Entscheidungsbäume sein. Feature Flags machen Software Releases überschaubarer, denn mit ihnen lässt sich Feature für Feature kontrollieren, was ein- oder ausgeschaltet ist.

Ihr e-Commerce Unternehmen kann beispielsweise ein Blue-Green Deployment seines Microservices Customizer durchführen, aber den neuen Code im Live-System hinter einem Feature Flag inaktiv lassen. Das DevOps-Team kann das betreffende Feature dann je nach gewünschter Bedingung zum gewünschten Zeitpunkt einschalten.

Eventuell möchte das Team weitere A/B-Tests in Produktion nehmen oder weitere Tauglichkeitstests vornehmen. Oder es könnte für das Team sinnvoller sein, für eine identifizierte Gruppe von Early UserInnen ein Canary Release des Customizer durchzuführen.

Ihre Feature Flags können zusammen mit einem Load Balancer bestimmen, welche UserInnen welche Applikation und Feature-Subsets während eines Blue-Green Deployments zu sehen bekommen. Statt ganze Applikationen auf einmal umzuschalten, können Sie auf die neue Applikation wechseln und dann im aktiven und inaktiven System nach und nach einzelne Feature aktivieren und deaktivieren, bis das Upgrade vollständig durchgeführt ist. Dieser schrittweise durchgeführte Prozess reduziert das Risiko und hilft Ihnen, Bugs aufzuspüren, da die einzelnen Features nach und nach live geschaltet werden.

Sie können Feature Flags manuell in Ihrer Codebase steuern oder für eine effektivere Steuerung Feature Flag Services verwenden. Diese Plattformen bieten ein detailliertes Reporting und KPI-Tracking sowie ein ausführliches Spektrum von DevOps Management-Tools.

Wir empfehlen Ihnen, Feature Flags zu verwenden, wenn Sie ein Blue-Green Deployment für einen größeren Release der Applikation durchführen. Sie sind auch in kleineren Deployments praktisch, bei denen Sie nicht unbedingt zwischen den Umgebungen umschalten. Sie können nach und nach Features in der blauen Umgebung einzeln aktivieren und die grüne Umgebung im Standby als Hot Backup verwenden, falls ein ernsthaftes Problem auftritt. Die Kombination aus Blue-Green Deployments und Feature Flags eignet sich ausgezeichnet für eine Continuous Delivery jeder Größenordnung.

Ziehen Sie in Betracht, Blue-Green Deployments in das Arsenal Ihrer DevOps hinzuzufügen

Blue-Green Deployments eignen sich bestens für Software Releases jeder Größe, egal, ob es sich um eine ganze Applikation, größere Updates, einen einzigen Microservice oder das Update eines kleinen Features handelt.

Bevor Sie sich für Blue-Green Deployments entscheiden, müssen Sie auf jeden Fall prüfen, wie gut sie sich in Ihren aktuellen Delivery Prozess integrieren lassen. In diesem Artikel haben wir erklärt, wie Blue-Green Deployments funktionieren, was für und was gegen ihre Verwendung in Ihrem Delivery Prozess spricht und wie sie sich von anderen möglichen Deployment-Methoden differenzieren. Sie sollten sich jetzt eine Vorstellung davon machen können, ob Blue-Green Deployments für Ihr Unternehmen in Frage kommen.

Der Beitrag Pros und Kontras von Blue-Green Deployments erschien zuerst auf abtasty.

Ein kritischer Punkt in der gesamten Product Experience ist User Onboarding: Wenn Sie alles richtig machen, gewinnen Sie loyale KundInnen. Machen Sie aber etwas falsch, verlieren Sie diese UserInnen für immer.

Also ist es sinnvoll, den User Onboarding-Prozess kontinuierlich zu optimieren – der perfekte Job für ein Produktteam. Ein solches Team setzt sich oft aus 5 bis 8 Mitarbeitern und Mitarbeiterinnen zusammen, u. a. aus ProduktmanagerInnen, DesignerInnen und EntwicklerInnen. Verschiedene Unternehmen arbeiten mit Produktteams unterschiedlicher Größe und Konfigurationen, je nachdem, was für ihren Use Case am besten ist. Allerdings sind DevOps Engineers selten Teil dieser Teams, denn für viele gelten DevOps nur als Instrument für erfolgreiche Feature Releases.

Letzten Endes sind es aber diese DevOps Engineers, die mitten in der Nacht aufstehen und ein neu implementiertes Feature korrigieren müssen, wenn es eine App zum Absturz bringt, sobald eine Userin oder ein User sich durch den Onboarding-Prozess navigiert.

Wir fragen Sie: Kann eine App, deren Onboarding-Prozess nicht funktioniert, erfolgreich sein, und haben Release Teams überhaupt einen signifikanten Einfluss auf die UX? Lassen Sie es uns herausfinden.

In diesem Artikel untersuchen wir genauer:
[toc content=“.entry-content“]

Wie Sie mit einer einwandfreien Onboarding-Experience dafür sorgen können, dass sich die UserInnen gleich heimisch fühlen

Die meisten Apps benötigen einen Onboarding-Prozess, um neuen UserInnen zu zeigen, wie sie ihre Ziele möglichst effizient und unkompliziert erreichen.

Dabei dürfen wir nicht vergessen, dass das Onboarding-Erlebnis Ihr Verhältnis zu potenziellen KundInnen beeinflussen kann – sowohl positiv als auch negativ.

Egal, wie gut Ihre App tatsächlich ist. Was zählt, ist der erste Eindruck!

Große Unternehmen wie Slack oder Dropbox überarbeiten häufig ihr User Onboarding, damit UserInnen bequem, heiter und zielführend in ihr Produkt einsteigen können. Überzeugen Sie sich selbst. Die folgenden Abbildungen zeigen einen Ausschnitt des Onboarding-Prozesses von Slack aus den Jahren 2014 und 2021. Das Design hat sich natürlich komplett geändert, aber statt der Beschreibung, wo der Name des Teams auf dem Interface von Slack später erscheint, werden nun das User Interface und der Name unseres Teams angezeigt. Diese Verbesserungen sind sicher nicht dem Zufall überlassen, sondern das Ergebnis sorgfältig koordinierter Optimierungsworkflows.

–

Da sogar große Unternehmen in die Optimierung ihrer Onboarding-Prozesse investieren, sollten auch wir das tun und uns nicht auf unseren Lorbeeren ausruhen. Es bleibt die Frage, wie Sie sicherstellen, dass Sie die richtige Onboarding-Experience auf die richtige Weise erstellen können?

Und genau hier kommen funktionsübergreifende Produktteams und Flagship ins Spiel!

Nutzen Sie Flagship, um Produktteams zusammenzubringen und eine einwandfreie UX sicherzustellen

Bei AB Tasty konzentrieren wir uns auf zwei Hauptthemen für eine einwandfreie User Experience:

1. Das richtige Feature veröffentlichen: Wir versetzen uns in unsere UserInnen und führen Experimente und Tests durch, damit das Feature einen Mehrwert und ein gutes Look and Feel bietet.
2. Das Feature richtig bereitstellen: Es geht nicht nur um Funktionalität und Look. Mit Feature Management stellen wir sicher, dass unser Produkt jederzeit und auf verschiedenen Plattformen einwandfrei funktioniert.
   –

–

Mit Flagship haben Sie die Mittel in der Hand, aus beiden Potenzialen das Beste herauszuholen: datenbasierte Experimente und Feature Management, um Features für einwandfreie Customer Experiences zu erstellen und zu veröffentlichen. Daher betrachten wir Release Teams als integralen Bestandteil in der Wertschöpfung für unsere UserInnen. Möglicherweise sind nicht alle derselben Auffassung. Trotzdem möchten wir Ihnen näher erklären, warum DevOps unserer Ansicht nach enger in die Produktteams eingebunden werden sollten.

Es ist kein Geheimnis, dass Teams, die ein gemeinsames Ziel verfolgen, ihr volles Potenzial eher erreichen als solche, die nicht dieselbe Richtung einschlagen. Wenn DevOps von Produktteams isoliert werden, können Sie wahrscheinlich nicht auf die positiven Effekte von Verbundenheit und leidenschaftlichem Einsatz zählen, die für die Entwicklung und den Release gelungener Produkte notwendig sind. Aus diesem Grund raten wir Produktteams, enger mit DevOps zusammenzuarbeiten. Auch Release Teams bemühen sich, UserInnen Mehrwert und großartige Experiences zu bieten. Und sie bringen die entsprechenden Skills dafür mit.

Flagship bietet ProduktmanagerInnen, EntwicklerInnen und DevOps Engineers eine gemeinsame Umgebung für Experimente und Feature Management. Sie haben alle Daten und Tools zur Hand, die Sie für ein produktives Gespräch über den Produktoptimierungsprozess in einer gemeinsamen datenbasierten Sprache brauchen. Spezifische Rollen und Verantwortlichkeiten werden nicht in Silos isoliert. Stattdessen kann sich jedes Mitglied des Produktteams auf seine Aufgabe konzentrieren und gleichzeitig weiterhin mit geballter Kraft arbeiten.

Werfen wir nun einen Blick darauf, wie Produktteams durch die Experimentier- und Feature Management-Funktionen von Flagship für herausragende User Experiences sorgen können.

Stellen Sie das Feature mit Feature Management richtig bereit

Sprechen wir zunächst über ein paar Beispiele, wie sich Feature Management und der richtige Release eines Features positiv auf das Onboarding-Erlebnis der UserInnen auswirken können.

Angenommen, Sie möchten Ihrem Onboarding-Prozess Tooltips hinzufügen, damit UserInnen sicher durch das Dashboard Ihres Produkts navigieren können. Das Produktteam bereitet das neue Feature entsprechend vor und testet seine Funktionsweise ausgiebig auf den Testservern. Nachdem alles zu funktionieren scheint, wird das neue Feature auf einen Schlag für alle UserInnen veröffentlicht. Hoffentlich nicht an einem Freitagnachmittag, denn die Umstellung könnte unvorhergesehene Probleme auf dem Produktionsserver verursachen, wie z. B.:

• Ihre UserInnen stecken in einer Endlosschleife, aus der es keinen Ausweg gibt
• Die Eingaben der UserInnen werden nicht gespeichert, z. B. in einem Formular
• Die App stürzt wiederholt ab
• Die UserInnen werden ohne ersichtlichen Grund wieder an den Start zurückgeschickt.

Stellen Sie sich vor, was das für die UserInnen bedeutet, die Ihren Onboarding-Prozess durchlaufen und sich schon darauf freuen, Ihr Produkt zu verwenden – und plötzlich funktioniert nichts mehr. Der magische Moment verpufft. Wegen einer schlechten UX haben die UserInnen höchstwahrscheinlich das Vertrauen in Ihre App verloren.

Flagship sorgt für eine stressfreie Code-Implementierung

Mit den Feature Management-Funktionen von Flagship können Ihre Produktteams neue Features unbesorgt veröffentlichen – sogar an einem Freitagnachmittag.

Mit Feature Management können Release Teams das neue Tooltips Feature einer ausgewählten Zielgruppe bereitstellen, bevor es für alle UserInnen veröffentlicht wird. Auf diese Weise können Sie sicher sein, dass das neue Feature unter realistischen Bedingungen funktioniert, d. h. auf Produktionsservern mit realen UserInnen.

Durch die Kontrolle und Überwachung der Rollouts wissen DevOps Teams sofort, wenn etwas nicht nach Plan verläuft. Dadurch können sie rechtzeitig reagieren und sich freuen, dass nur wenige UserInnen den Fehler bemerkt haben.

Nehmen wir zum Beispiel an, die EntwicklerInnen haben das Tooltip Feature in ein Feature Flag gepackt (was sie wirklich tun sollten). In diesem Fall können sie das Feature bei einem Problem schnell über das Flagship-Dashboard deaktivieren. Selbstverständlich können sie auch automatische Code-Rollbacks auf Basis von KPIs konfigurieren, um noch schneller zu reagieren.

Richtiges Feature Management kann gestresste Release Teams entlasten: Es macht Schluss mit schlaflosen Nächten zur Schadensbegrenzung! Wenn Sie mehr über die Vorteile von Feature Management für Tech Teams erfahren möchten, empfehlen wir Ihnen unseren Blogpost.

Veröffentlichen Sie das richtige Feature mit Experimenten

Vielleicht können Sie sich gut in Ihre Produktteams hineinversetzen und haben den Eindruck, Ihre UserInnen ziemlich gut zu kennen. Trotzdem sind Experimente und Tests sinnvoll, um einen Onboarding-Prozess zu erstellen, der Ihre UserInnen begeistert.

Werfen wir noch einmal einen Blick auf das Tooltip-Beispiel von vorhin. Angenommen, Ihr Produktteam hat die Tooltips erfolgreich im User Onboarding-Prozess integriert. Ihre Analysedaten weisen jedoch darauf hin, dass etwas nicht stimmen kann. Viele UserInnen wissen immer noch nicht, wie Ihre App genutzt wird, und brechen den Prozess auf halbem Weg ab. Wenn Sie das Problem nicht sofort identifizieren und beheben können, müssen Sie auf andere Mittel zurückgreifen, um die User Experience des Tooltips zu verbessern.

Stellen Sie zunächst sicher, dass aus technischer Sicht alles in Ordnung ist. Als Nächstes sollte Ihr Produktteam an möglichen Varianten im Hinblick auf eine bessere Präsentation und Funktionalität von Tooltips arbeiten. Sie können dann mit Experimenten und Tests in Flagship festlegen, welche Varianten und Ideen die beste User Experience bieten.

Zum Beispiel könnten Sie mit A/B-Tests herausfinden, ob ein Anleitungsvideo für UserInnen hilfreich wäre, bevor die Tooltips angezeigt werden und sie mit dem Produkt starten. Oder experimentieren Sie mit der Abfolge der Tooltips – vielleicht ist der Prozess verständlicher, wenn Sie die Reihenfolge der Tooltips ändern.

Sie können auch mit verschiedenen Farben, Texten, UI-Elementen, Call-to-Action usw. experimentieren. Damit Ihre Experimente möglichst aussagekräftig sind, können Sie festlegen, welche UserInnen welche Feature-Variante zu sehen bekommen, und die Nutzerakzeptanz, Testergebnisse und KPIs im Flagship-Dashboard verfolgen.

Ein weiterer Vorteil von Flagship ist die mögliche Verwendung einer 1-zu-1-Personalisierung auf Basis von Zielgruppensegmenten, um UserInnen einzigartige Erlebnisse zu bieten. Zum Beispiel können Sie UserInnen nach der Registrierung für ein zahlungspflichtiges Abo eine personalisierte Begrüßungsnachricht anzeigen und ihrem Onboarding-Erlebnis so einen Mehrwert verleihen.

… Was ist mit clientseitigen Tools für Experimente?

Viele clientseitige Tools für die Experience-Optimierung, wie beispielsweise unser AB Tasty Tool, können die meisten dieser Experimente ebenfalls durchführen – und das ohne Code-Deployment. Wenn Sie Ihre Experimente für einen kritischen Prozess wie User Onboarding codieren, hat das allerdings folgenden Vorteil: Sie verlangsamen den Prozess nicht potenziell mit automatisch generierten UI-Overlays. Hingegen sind Tests und Experimente mit Flagship schnell, sicher und „flickerfrei“, da sie direkt vom Server kommen und nicht im Browser der UserInnen berechnet werden müssen. Selbstverständlich haben clientseitige Tools nach wie vor ihre Berechtigung und ihre einzigartigen Einsatzmöglichkeiten – Flagship ist ein großartiges Tool, um Ihre clientseitige Strategie zu ergänzen.

Takeaway

Wenn Sie UserInnen die bestmögliche Onboarding-Experience bieten möchten, brauchen Sie funktionsübergreifende Teams, die wissen, wie das richtige Feature richtig veröffentlicht wird. Eines unserer Ziele ist es, die Bedeutung von Release Teams für eine einwandfreie UX zu propagieren – ob ein Produkt technisch einwandfrei funktioniert, ist genauso wichtig wie sein Erscheinungsbild und sein Verhalten.

Mit den Experimentier- und Feature Management-Funktionen von Flagship können Produktteams von einer Plattform profitieren, um zusammen produktiv und datenbasiert an der Verbesserung des Onboarding-Erlebnisses zu arbeiten.

Sie möchten Flagship für Ihre Produktteams ausprobieren? Buchen Sie eine Demo und sehen Sie wie Experimente und Feature Management die Onboarding-Experience Ihrer UserInnen von „okay“ zu „super“ verändern können.

Der Beitrag Use Case User Onboarding: Welchen Einfluss haben Release Teams auf die UX? erschien zuerst auf abtasty.