Null Toleranz für Fehler: Wie wir auf otto.de die Qualität hoch halten

Transkript

1 Null Toleraz für Fehler: Wie wir auf otto.de die Qualität hoch halte Null Toleraz für Fehler: Wie wir auf otto.de die Qualität hoch halte Wie schafft ma dutzede Live-Deploymets pro Woche auf eier der größte E-Commerce-Plattforme i Europa? Um permaet eue Features ud Korrekture ausliefer zu köe, wird eie wesetliche Igrediez beötigt: automatisierte Qualität. Mit userer Geschichte eies Bugs verfolge wir i diesem Artikel eie kokrete Fehlerbehebug auf otto.de ud gebe praktische Tipps für Qualität i der agile Softwareetwicklug. Mit dem erfolgreiche Abschluss des Projekts Lhotse (vgl. [Lho13]) habe wir Ede 2013 otto.de auf eue Beie gestellt: Eie Idividual- ud Eigeetwicklug auf Basis vo Ope-Source-Kompoete hat die bestehede Stadardsoftware ersetzt. Der Projektmaagemet-Prozess wurde auf Scrum umgestellt. I der Softwareetwicklug setze wir auf aus dem extreme Programmig (XP) bekate Praktike: Collective Owership Pair-Programmig Test-Drive Developmet Cotiuous Itegratio Etwas mehr als ei halbes Jahr ach dem Go-Live ist die Plattform weiterhi eiem permaetem Wadel uterworfe. Die fachliche ud techische Aforderuge a eie Software im hoch dyamische E-Commerce-Umfeld wachse täglich. Die Möglichkeite bei der freie Gestaltug userer Idividualetwicklug ud der hausiter aufgebaute Kompetez wolle geutzt werde, um och scheller Abb. 1: Teaser mit ud ohe Streichpreis. am Markt agiere zu köe. Daher wird otto.de auch ach dem Lauch der eue Plattform mit eiem über hudertköpfigem Team kotiuierlich verbessert ud weiteretwickelt. Die kotiuierliche Etwicklug ist jedoch ur der halbe Weg. Neue Features ud Bug-Fixes solle schellstmöglich zum Edkude. Um dies zu erreiche, habe wir verschiedee Techike ud Prozesse implemetiert, die sich uter Cotiuous Delivery (vgl. [Hum10]) zusammefasse lasse. Damit verkürze wir die Durchlaufzeit vo der Etwicklug bis zur Ibetriebahme ud schaffe astelle vormals moatlicher Feature-Releases u mehrere Live-Deploymets pro Tag. Damit das fuktioiere ka, ist ei Aspekt besoders wichtig: Gleichbleibed hohe Qualität muss automatisiert sichergestellt werde. Wie stelle wir bei otto.de Qualität automatisiert sicher ud wie sieht das kokret i userem Softwareetwicklugsprozess aus? Dies beschreibe wir im Folgede ahad eies kokrete Awedugsfalls. Los geht es mit userer Geschichte eies Bugs... 13:00 Uhr: Warum wird der Streichpreis icht agezeigt? Kurz ach dem Mittagesse bekommt das Team Etdecke eie Aruf aus dem Produktmaagemet: A de Produkt- Teaser wird der Streichpreis icht agezeigt (siehe Abbildug 1). Dieser ist ei wichtiges Verkaufsargumet, da der Kude damit auf eie Preisreduktio aufmerksam gemacht werde ka. Die Fehlermeldug wird a de zustädige Qualitätsmaager im Team weitergeleitet. Der versucht, de Fehler zu verifiziere, ud aalysiert de Sachverhalt. Dabei schließt er uter aderem bereits aus, dass ei Fehler i de Date vorliegt. Liegt tatsächlich ei Fehler Usere agile Etwicklugsteams sid immer eier kokrete Fachdomäe zugeordet, i userem Beispiel der Domäe Etdecke, ud besitze daher umfassedes fachliches sowie techisches Wisse i der Domäe. Weiterhi sid die Teams cross-fuktioal aufgestellt ud habe z.b. immer eie dedizierte Qualitätsmaager. Das Team ist somit i der Lage, die jeweilige Fachdomäe vollstädig zu bearbeite. Kaste 1: Alle Kompetez i das Team gebe. vor, legt er i userem Bug-Tracker eie eue Bug a ud dokumetiert ih etspreched. Gleichzeitig kommt der Bug zusamme mit der vom System vergebee ID auf das Task-Board, sodass das gesamte Team (siehe Kaste 1) sieht, dass ei euer Fehler gefude wurde. Hierfür gibt es auf dem Task-Board eie so geate Bug-Lae (siehe Abbildug 2). 14:00 Uhr: Ei euer Bug am Task-Board Zwei Etwickler (siehe Kaste 2) aus dem Team Etdecke arbeite heute zusamme ud habe soebe eie Aufgabe abgeschlosse. Vom Task-Board des Teams hole sie sich u eie eue Aufgabe. Bei der Auswahl eier eue Aufgabe folge wir eifache Regel. Die Abarbeitug der Aufgabe erfolgt gemäß der Priorisierug Bugs vor Storys (Zero-Bug-Policy, siehe Kaste 3). Diese Priorisierug wird am Task-Board trasparet. Bugs werde als Task-Zettel i der oberste Zeile dargestellt. Daruter liegede Zeile ethalte je eie Story mit de zugehörige Tasks. Tasks 18

2 Mit eier Zero-Bug-Policy vermeide wir, dass usere mit zwei Jahre och relativ juge Software schleiched immer fehlerbehafteter wird ud dass wir mehr Zeit mit der Priorisierug ud Behebug vo Fehler verbrige als mit der Etwicklug euer Fuktioe. Alle i der Software offee Bugs sid für usere Etwickler trasparet ud auch der Zeitpukt für die Behebug ist uabhägig vo der Kritikalität mit sofort geklärt. Ei Bug wird ierhalb vo 24 Stude behobe ud grudsätzlich vor der ächste User-Story bearbeitet. Kaste 3: Kei Fehler wird toleriert. Abb. 2: Task-Board mit Bug-Lae obe. wader je ach Bearbeitugsstatus durch die Spalte Tasks, I Progress, I-Test ud da ach Doe. Damit arbeite wir vo obe ach ute ud vo liks ach rechts ud erfülle somit usere Zero-Bug-Policy. Der Bug-Task Fehlerhafter Streichpreis auf Produkt-Teaser wird vo de Etwickler i die Spalte I-Progress bewegt ud diese begie mit der Arbeit. 15:10 Uhr: Wir begebe us auf die Fehlersuche Damit wir de Fehler behebe köe, müsse wir ih zuächst wiederholbar reproduziere. Dafür schreibe wir eie Uit-Test, der de geforderte korrekte Streichpreis beschreibt. Dieser Uit-Test schlägt atürlich fehl, da der Fehler och icht behobe wurde. I diesem Stadium der Fehlerbehebug vervollstädigt er aber usere Systembeschreibug ud hilft bei der Lokalisierug des Fehlers im Produktioscode (siehe Kaste 4). Wir beutze Pair-Programmig, um für eie gute Wissesverteilug über das Team hiweg zu sorge. Die Kozetratio ud die Fokussierug auf die Aufgabe ka über lägere Zeit aufrechterhalte werde. Neue Mitarbeiter köe so eifacher eigearbeitet werde ud icht zuletzt macht es eifach mehr Spaß. Kaste 2: Vier Auge sehe mehr als zwei. Beim Schreibe des Tests halte wir us a eiige eifache Muster: Sigle-Resposibility Um sicherzustelle, dass auch ur geau ei Aspekt der Software getestet wird, hilft es, ierhalb der Testmethode die Kommetare //give, //whe, //the i dieser Reihefolge geau eimal zu verwede. Ei Test testet zu viel, we der Etwickler versucht ist, eie zweite Vorbedigug oder Ausführug sprich ei ereutes give oder whe ach eiem the zu verwede. Aussagekraft Wird ei Test rot, muss der Etwickler auf eie Blick erkee, welche Fuktio der Software betroffe ist. Eie aussagekräftige Methodesigatur hilft dabei weiter. Außerdem ist es wichtig zu sage, was der Test als Ergebis erwartet, ud icht, was er zu teste versucht. Das ka ma leicht erreiche, idem ma seie Methode mit should begie lässt ud icht mit dem obligatorische test De Uit-Test für de Fehler i der Streichpreis-Berechug ee wir also should- ShowStreichpreisForReducedProduct astelle vo teststreichpreislogic. Stabilität Usere Software befidet sich i städiger Veräderug. Trotzdem wolle wir icht mit jeder kleie Apassug die Uit- Tests ebefalls apasse müsse. Erhält das Beutzerobjekt z.b. ei weiteres Feld für eie eue Eigeschaft des Beutzers, so solle möglichst alle bereits bestehede Uit-Tests weiterhi stabil laufe ud vo der Äderug uberührt bleibe. Um dieses Ziel zu erreiche, bietet es sich a, die Objekte über eie spezielle Factory, die so geate Fixtures, zu erzeuge. Die Factory-Methode eies Fixtures erzeugt ei Default-Objekt. Um die Defaults zu überschreibe, werde etsprechede Methode zur Verfügug gestellt. Ei Fixture lässt sich am beste mit dem Builder-Patter realisiere: User user = ew UserFixture().withFirstame( Has ). withlastame( Dampf ).build(); Uabhägigkeit Uit-Tests sollte uabhägig voeiader gestaltet werde. Dabei sollte jeder Test seie eigee Testdate erzeuge. Weiterhi Wir verstehe Testcode icht als Wegwerfcode: Testcode uterliegt de gleiche Aforderuge wie Produktivcode ud ka diese sogar überdauer. Uit-Tests beschreibe das System ud sollte auch als Teil der Dokumetatio verstade werde. Tests sid die Basis für Äderuge am Produktivcode, de wir aschließed beliebig refaktorisiere köe. Kaste 4: Testcode ist Code erster Klasse. 04/

3 Null Toleraz für Fehler: Wie wir auf otto.de die Qualität hoch halte Dass eie icht abgeommee Fuktioalität auf dem Produktivsystem icht zur Ausführug kommt, verhider wir mit so geate Feature Toggles. Feature-Braches verwede wir i userer Versiosverwaltug higege fast ie. Die eue Fuktioalität wird durch eie Schalter zuächst deaktiviert. Nach der Qualitätssicherug ud der fachliche Abahme ka die Fuktioalität da aktiviert werde. Sämtliche Etwickluge fide auf eiem eizige Brach statt, so auch user Bug-Fix. Das hat verschiedee Vorteile: Erstes werde kokurrierede oder problematische Äderuge am Code früh erkat ud zweites werde Deploymet ud Aktivierug euer Features voeiader etkoppelt. Kaste 5: Toggles statt Braches. dürfe keie gemeisame Felder ierhalb eier Testklasse verwedet werde ud die Tests dürfe keie Abhägigkeite utereiader aufweise. So wird sichergestellt, dass ei fehlschlageder Uit-Test de Defekt im Code geau beet. Abhägigkeite erschwere die Fehlersuche. Um zu erkee, ob die Uit-Tests uabhägig voeiader laufe, köe wir diese parallel ausführe. Die Azahl der Threads, die Uit-Tests bearbeite, lässt sich i Frameworks wie beispielsweise TestNG bequem kofiguriere. Parallel laufede Tests sorge zum eie für eie deutlich verkürzte Laufzeit der Test-Suite ud köe zum adere Nebeläufigkeitsprobleme der Software aufdecke. Mit dem Uit-Test habe wir u icht ur de Bug gefude, soder auch eie Wert für die Zukuft geschaffe. Der eue Test wird us zuküftig als Regressiostest diee, um sicherzustelle, dass der gefudee Fehler i der Streichpreis-Berechug icht ereut auftritt. Bleibt ur och, de Fehler auch wirklich zu beseitige. 15:30 Uhr: Rot Grü Refaktorisiere Die Etwickler habe u eie fehlschlagede ud damit rote Uit-Test geschaffe. Dieser Test lässt sich i der Folge beliebig oft ausführe ud gege diese Uit-Test etwickel sie jetzt de Bug-Fix. Damit folge wir auch bei der Behebug vo Fehler dem Asatz des Test-Drive- Developmet (TDD). Sobald der Test grü geworde ist, habe wir och eimal die Möglichkeit, de geschriebee Code für de Bug-Fix zu refaktorisiere, damit dieser usere Aforderuge geügt. Geau das habe die Etwickler geta. Sie habe de Fehler i der Streichpreis- Berechug beseitigt. Der Bug-Fix muss u als Commit i die Versiosverwaltug überomme werde. 15:55 Uhr: Wir publiziere de Code Nicht ur der Test für diese Bug-Fix ist ei Regressiostest, soder jeder Uit- ud jeder Akzeptaztest, de wir je geschriebe habe. Bevor wir de Code i das Versiosverwaltugssystem überehme, führe wir sämtliche Tests och eimal aus. So bemerke wir ierhalb weiger Miute, ob wir mit dem Bug-Fix ei aderes Verhalte der Software verädert habe. Sid keie Fehler aufgetrete, fasse wir die Äderuge im Rahme des Bug-Fix i eiem Commit zusamme. Der Commit wird mit eier kurze, aussagekräftige Beschreibug versehe. Ebeso wie beim Uit-Test soll hiermit das gewüschte Verhalte der Software dokumetiert werde. Außerdem ethält die so geate Commit-Message die vom Bug-Tracker vergebee ID sowie die Kürzel der beteiligte Etwickler. Damit lässt sich später eifach achvollziehe, welche Zweck eie bestimmte Äderug im Code hatte. Es ist 16:00 Uhr. Da alle Tests erfolgreich durchgelaufe sid, ka der Bug-Fix i de Hauptzweig (siehe Kaste 5) des Versiosverwaltugssystems überomme werde. Tools für die Erstellug vo Softwaremetrike wie Fidbugs, Checkstyle, PMD oder Cobertura diee us ur als Uterstützug bei der Etwicklug. Die Bestimmug der Güte eies Artefakts ud damit die Markierug eies potezielle Live-Kadidate erfolge bei us ur durch die absolvierte Tests. I der Etwicklug fokussiere wir us somit i erster Liie auf eie hohe Qualität ud die Erfüllug der Aforderuge, statt auf das Eihalte vo Softwaremetrike. Kaste 6: Brauche wir icht och Softwaremetrike? 16:01 Uhr: Die Build- Pipelie läuft a Kurz achdem die eue Softwareversio mit dem ethaltee Bug-Fix i das Versiosverwaltugssystem überomme wurde, wird der Build-Server aktiv. Dort wird miütlich geprüft, ob eie eue Softwareversio vorliegt. Ist das der Fall, wird diese aus der Versiosverwaltug ausgecheckt ud da ei Durchlauf der Build-Pipelie gestartet. Die Aufgabe der Build-Pipelie besteht aus dem Erzeuge eies Artefakts, der acheiader i verschiedee Umgebuge istalliert ud dabei diverse automatisierte ud auch mauelle Tests uterzoge wird. Im Folgede betrachte wir eie vereifachte Versio userer Build-Pipelie (vgl. [Je13], siehe Abbildug 3). Eiige Details sid hier bewusst ausgelasse, damit im Rahme dieses Artikels och eie übersichtliche Darstellug gelige ka. Trotzdem köe wir eiige iteressate Aspekte beleuchte. Nach dem Checkout der eue Versio des Quellcodes aus dem Versiosverwaltugssystem wird zuächst der Commit-Build agestoße. Dieser uterscheidet sich zuächst icht wesetlich vom Testdurchlauf auf dem lokale Etwicklersystem. Der Code wird kompiliert ud die komplette Suite der automatische Tests wird ausgeführt. Im Eizele sid das: Abb. 3: Schematische Darstellug eier vereifachte Build-Pipelie. Uit-Tests Akzeptaztests eifache Ede-zu-Ede-Tests mithilfe vo Seleium 20

4 Um bei der tägliche Arbeit stets hadlugsfähig zu bleibe, habe wir klare Prioritäte festgelegt, i welcher Reihefolge welche Probleme i usere Systeme agegage werde: Probleme i der Build-Pipelie werde zuerst agegage, de ohe diese habe wir keie Chace, usere Software i die verschiedee Umgebuge zu deploye isbesodere auch icht i die Produktivumgebug. Alle Umgebuge müsse stets fehlerfrei fuktioiere, da sost automatisierte ud mauelle Tests icht stattfide köe. Bugs werde behobe, um die i diesem Artikel erwähte Zero-Bug-Policy eihalte zu köe. Neue fachliche Fuktioe habe die iedrigste Priorität. Fidet der Qualitätsmaager doch och eie Fehler, muss er icht ur warte, bis dieser durch die Etwickler behobe ist. Es addiere sich midestes och die geate 21 Miute, die die Build- Pipelie beötigt, um wieder a diese Pukt zu komme. Auch deshalb ist es wichtig, dass automatisierte Tests so schell wie möglich ablaufe. Kaste 8: Eie schelle Build-Pipelie. Die Folge dieser Priorisierug ist icht etwa, dass keie eue Fuktioalität mehr umgesetzt wird, soder im Gegeteil eie gleichmäßige ud vorhersagbare Abarbeitug vo fachliche Storys. Da keie techische Schulde agehäuft werde, kommt es auch viel selteer zu uliebsame Überraschuge. Kaste 7: Eie Frage vo Prioritäte. Itegratiostests gege adere Softwaresysteme fide erst später statt. Sid alle Tests erfolgreich, wird ei Artefakt, d. h. eie deploybare Versio der Software, erzeugt ud mit der Nummer des aktuelle Commit-Builds versioiert (für eie Diskussio zur Verwedug vo Softwaremetrike i der Build-Pipelie siehe Kaste 6). Die folgede Schritte verwede alle exakt dieses Artefakt, das sich vo u a icht mehr äder wird. Ist ur ei eiziger Test fehlgeschlage, wird die Pipelie a dieser Stelle agehalte (siehe Abbildug 4). Es dürfe da keie Äderuge mehr i das Versiosverwaltugssystem überomme werde, bis die Build-Pipelie wieder fehlerfrei durchläuft (siehe Kaste 7). Dak der testgetriebee Etwicklug userer Software sid eiige taused Tests ausgeführt worde. Deshalb köe wir us i de u folgede Schritte auf weige Tests beschräke, die im Wesetliche die Itegratio userer Software mit de Umsysteme betreffe. 16:07 Uhr: Ausrolle i die Testumgebug Dazu wird im ächste Schritt der Build- Pipelie usere Software auf die Testumgebug deployed. Auf dieser fide sowohl mauelle als auch automatisierte Tests statt. 16:11 Uhr: Automatisierte Oberflächetests Zu de verschiedee Arte vo automatisierte Tests gehöre uter aderem eifache Ede-zu-Ede-Tests. Diese besuche i userem Fall mit eiem Web-Browser die itegrierte Webseite ud prüfe, ob die wesetliche Elemete vorhade sid. Dak der hohe Testabdeckug währed des Commit-Build geügt es dabei zu prüfe, dass bestimmte Kompoete vorhade sid. Dass diese im Detail korrekt fuktioiere, wisse wir bereits aus de etsprechede Uit-Tests. I userem Beispiel bedeutet dies: Der Ede-zu-Ede-Test muss ur prüfe, dass auf dem Produkt-Teaser ei Streichpreis a der richtige Stelle agezeigt wird. Ob dieser Preis korrekt berechet ist, wird icht mit diese vergleichsweise lagsame ud aufwädige Tests geprüft. Zu viele Parameter müsste berücksichtigt werde. Dafür sid die viel schellere Uit-Tests im Commit- Build zustädig. 16:11 Uhr: Schittstelle testet der Verweder Gleichzeitig mit de Ede-zu-Ede-Tests starte die ebefalls voll automatisierte Lasttests, die ei realistisches Hochlastszeario simuliere, sid recht aufwädig. Etweder beutzt ma Lastagete, die mithilfe echter Browser ud etsprecheder Ausführug vo JavaScript eie realistische Last erzeuge, was sehr ressourceitesiv ist. Die Alterative sid Tests mit eifachere Agete, die zum Beispiel mit jmeter-skripte implemetiert sei köe. Diese Skripte sid wiederum pflegeitesiv, da ma die clietseitig ausgelöste Afrage mauell überehme muss. Beide Variate beötige Zeit ud Ressource, weshalb sie i der auf Hochgeschwidigkeit getrimmte Build-Pipelie keie Platz habe. Lasttests fide also uabhägig vo der Build-Pipelie statt. Abb. 5: Die Ede-zu-Ede-Tests ud die CDC-Tests laufe parallel. Kaste 9: Ud was ist mit Lasttests? 04/

5 Null Toleraz für Fehler: Wie wir auf otto.de die Qualität hoch halte Abb. 4: Ei eiziger fehlschlageder Test lässt de Build scheiter. Cosumer-Drive-Cotract-Tests (CDC- Tests) (vgl. [Fow06], siehe Abbildug 5), die prüfe, ob die Schittstelle ikompatibel geädert wurde ud ob somit die Software eies Teams icht mehr korrekt fuktioiert. CDC-Tests sid bei otto.de wie folgt implemetiert: Die Tests werde vo dem Team erstellt ud gepflegt, das eie Schittstelle verwedet. Sie sid Teil der Software dieses Teams ud liege i desse Versiosverwaltugssystem. Um die CDC-Tests auszuführe, checkt der Build-Server des schittstelleabietede Teams de Quellcode des adere Teams aus, kompiliert diese ud führt da de etspreched markierte Teil der Test-Suite aus. Dabei wird die Kofiguratio so agepasst, dass usere gerade istallierte Software Ziel der etsprechede Schittstelleaufrufe wird. Das verwedede Team ka so seie Erwartuge a die Schittstelle dokumetie- re ud automatisiert prüfe. Schlägt ei CDC-Test fehl, bedeutet das, dass wir eie zuvor och fuktioierede Schittstelle auf eie ikompatible Weise geädert habe. Usere Build-Pipelie wird agehalte ud wir köe us auf die Suche ach der Ursache des Problems mache. Das verwedede Team erfährt idealerweise gar ichts vo dem Vorfall ud muss sich isbesodere icht plötzlich um ei icht fuktioieredes Produktivsystem kümmer ud eie Fehler recherchiere, de es icht selbst verursacht hat. 16:22 Uhr: Exploratives Teste Seit dem Eichecke des Bug-Fixes i die Versiosverwaltug sid 21 Miute vergage. Wir wisse bereits, dass die Fuktioalität der Software icht ubeabsichtigt verädert wurde, dass die Itegratio i die Laufzeitumgebug geluge ist ud dass die Schittstelle weiterhi fuktioiere. Somit ist die Wahrscheilichkeit hoch, dass der Qualitätsmaager ei fuktioieredes System vorfidet (siehe Kaste 8). Er ka sich also darauf kozetriere, die eue Fuktioalität i userem Fall die korrekte Streichpreis-Logik zu teste. Währed der mauelle Tests wird eie Grudlast auf das System gegebe. Dies ist eie ereute Gelegeheit, durch Nebeläufigkeitseffekte verursachte Fehler aufzudecke. Auf explizite Lasttests ierhalb der Pipelie verzichte wir bewusst (siehe Kaste 9). 16:30 Uhr: Geeralprobe auf dem Stagig-System Nachdem sowohl automatisierte, als auch mauelle Tests erfolgreich ware, wird das Artefakt i die ächste Umgebug deployed. Diese ist der aktuelle Produktivumgebug so ählich wie möglich. Hier laufe och eimal dieselbe automatisierte Tests ab wie scho zuvor auf der Testumgebug. Für die CDC-Tests wird u die aktuell auf dem Live-System befidliche Versio der Schittstelleverweder beutzt. Diese ist gewöhlich ei weig älter als die i der Testumgebug istallierte. Es fidet weiterhi eie ereute mauelle Abahme statt. Ählich wie die Ede-zu- Ede-Tests aufgrud der detailliertere Uit-Tests auf Details verzichte köe, ka sich der Qualitätsmaager auf seie i der Testumgebug erfolgte fachliche Tests stütze ud ur och die korrekte Itegratio der Software i die Produktivumgebug prüfe. Nu ka die korrigierte Versio der Software auf dem Produktivsystem ausgerollt werde (siehe Die Autore Robert Breetzma (Robert.Breetzma@otto.de) ist seit seiem Studium der Iformatik a der Etwicklug vo freier Software ud der Verwedug euer Techologie iteressiert. Seit 2007 etwickelt er große E-Commerce-Systeme ud ist seit 2011 als Softwareetwickler bei Otto tätig. Stepha Kraus (Stepha.Kraus@otto.de) hat über zeh Jahre Erfahrug i der Etwicklug ud dem Betrieb vo große Web-Aweduge ud E-Commerce-Sites. Er ist Teamleiter Softwareetwicklug im Bereich E-Commerce bei OTTO i Hamburg. Christia Stamm (Christia.Stamm@otto.de) ist Diplom-Iformatiker. Er etwickelt seit mehrere Jahre große Iteretsysteme, ist begeistert vo agile Etwicklugsmethode ud spricht über diese auch auf Kofereze. 22

6 Abbildug 6). Dak Blue/Gree-Deploymet (vgl. [Fow10]) erfolgt das Ausrolle uterbrechugsfrei ud vo de Kude ubemerkt. 16:45 Uhr: Wir gehe live Der Bug-Fix ist u auf dem Produktivsystem agekomme. Vo der Etdeckug des Bugs bis zu seier Behebug im Produktivsystem ist weiger als ei Arbeitstag vergage. Am Beispiel der Behebug eies Fehlers i der Streichpreis-Logik habe wir gezeigt, wie wir auf otto.de die Qualität dauerhaft hoch halte: Fehlerbehebug hat immer Vorrag vor euer Fuktioalität. Mit viele automatisierte Tests halte wir das System fehlerfrei ud dokumetiere gleichzeitig desse Eigeschafte. Die vorgestellte Methode uterstütze us icht ur bei der Behebug vo Fehler, soder atürlich auch bei der Etwicklug euer Fuktioalität. Durch eie hohe Grad a Testautomatisierug ud die Verwedug eier Build-Pipelie etwickel wir icht ur effiziet, soder stelle auch Äderuge mit eier hohe Frequez auf otto. de live. Abb. 6: Nachdem alle Tests erfolgreich ware, ka ei Go-Live erfolge. Literatur & Liks [Fow06] M. Fowler, Cosumer-Drive Cotracts: A Service Evolutio Patter, 2006, siehe: [Fow10] M. Fowler, BlueGreeDeploymet, 2010, siehe: [Hum10] J. Humble, D. Farley, Cotiuous Delivery. Reliable Software Releases Through Build, Test, ad Deploymet Automatio, Addiso-Wesley 2010 [Je13] Jekis, Build Pipelie Plugi, 2013, siehe: [Lho13] Lhotse Ei Code für alle Fälle OTTOs eigee Shoppigsoftware, siehe: 04/