Die Reise nach DevOps: Auf dem Weg zu einer bedarfsgerechten IT

Transkript

1 Die Reise ach DevOps: Auf dem Weg zu eier bedarfsgerechte IT Die Reise ach DevOps: Auf dem Weg zu eier bedarfsgerechte IT Dieser Artikel wirft eie Blick auf die Herkuft ud die absehbare Etwicklug vo DevOps. Die Etstehug ud das spätere Scheiter des traditioelle Software-Egieerigs werde agesproche, um aschließed auf die Theme Agilität ud DevOps eizugehe, wobei die Grüde für das uterschiedlich erfolgreiche Fuktioiere dieser Kozepte erläutert werde. Mit Hiweis auf häufige Missverstädisse i Bezug auf DevOps wird abschließed ei Ausblick auf die Zukuft dieses Themas gewagt. Die Afäge Gaz am Afag war Chaos u ja, icht ur Chaos, aber i de frühe 1960er dachte weige über Prozessmodelle, arbeitsteilige Orgaisatiosstrukture ud aufwädige Goverace-Modelle ach. Software wurde auf Zuruf der Fachabteiluge etwickelt, was dazu führte, dass komplexe Software im Vergleich zu Hardware kostspielig wurde. Über eie Treug vo Etwicklug ud Betrieb machte sich och iemad Gedake. Ma war och weit etfert vo eier durchgägige IT-Uterstützug gazer Geschäftsprozesse. Außerdem ware die Aweduge voeiader isoliert bis zu eier durchgägige Veretzug vo Recher ud Software sollte es och viele Jahre dauer. Diese Heragehesweise war so gegewärtig, dass sie irgedwa a ihre Greze stieß. Der Bedarf a Software überstieg die Lieferfähigkeit deutlich, die Softwarekrise (vgl. [Wiki-a]) war gebore (siehe auch Abbildug 1). Auf eier NATO-Koferez im Jahr 1968 i Garmisch-Partekirche (vgl. [NATO]) wurde diese Problemstellug diskutiert. Dies war die Geburtsstude des Software- Egieerigs, eies Produktiosmodells für die Softwareetwicklug. Doch wora orietiere? Als hilfreich erwies sich, dass ei ählich gelagertes Problem Afag des 20. Jahrhuderts bereits i eiem adere Idustriezweig erfolgreich gelöst worde war. Hery Ford hatte vorgemacht, wie ma die Produktio vo Automobile um bedeutsame Größeorduge steiger kote, um de Bedarf des riesige Marktes auf kosteeffiziete Weise zu decke (vgl. [Wiki-b]): Er spaltete de gesamte Produktiosprozess i eizele Schritte auf ud ließ diese da vo Spezialiste (beim Autobau i der Regel vo agelerte Arbeiter) ausführe ud verbad diese per Fließbad miteiader. Iteressaterweise ist dieser Asatz heute primär uter dem Begriff Taylorismus (vgl. [Wiki-c]) bekat, beat ach Frederick Wislow Taylor, der sehr ähliche Idee zeitgleich zu Ford etwickelt hatte. Bis heute ist icht eideutig geklärt, i welchem Maße sich die Idee gegeseitig beeiflusst habe. Aufgrud der größere Verbreitug verwede wir i diesem Artikel im weitere Verlauf de Begriff Taylorismus. Durch de Taylorismus etstad ei kotiuierlicher Produktiosfluss, der ahezu beliebig skaliert werde kote ud Koste reduzierte eimal wege der Losgrößeeffekte, aber auch, weil es icht mehr otwedig war, teure Experte zu beschäftige, die ei Automobil i Gäze verstehe ud baue kote. Vielmehr war es ausreiched, Arbeitskräfte zu utze, dee ma ur bereits vorgedachte Hadgriffe beibrige musste. Diese Idee griffe die Begrüder des Software-Egieerigs auf ud damit hielte Abb. 1: Vo der Softwarekrise bis zu DevOps. Prozessmodelle, Arbeitsteilug ud Spezialisierug Eizug i die IT: Es wurde zwische Aalyse, Desig, Implemetierug, Test, Ibetriebahme ud Betrieb uterschiede ud ma bega, die eizele Disziplie weiter auszuarbeite ud zu spezialisiere. Tatsächlich ist Software-Egieerig viel mehr als ur ei Übertrage der Idee des Taylorismus auf die Softwareetwicklug, aber das würde de Rahme dieses Artikels sprege. Greze ud eue Herausforderuge Die Kozepte des Software-Egieerigs aus de späte 1960er ud de frühe 1970er wurde über die Jahre immer weiter verfeiert ud perfektioiert auch we heute kaum och jemadem bewusst ist, welche Herausforderuge damit ursprüglich gemeistert werde sollte. Aber auch ach über 40 Jahre Ahäufe ud Verfeier vo Wisse ist die Soft- 10

2 warekrise icht überwude. Der Zielzustad ist och immer icht erreicht: Neue Aforderuge müsste i kürzester Zeit ausgeliefert werde, ud zwar zu immer güstigere Preise. Das ist aber icht der Fall. Die Softwarekrise gilt zwar als beedet, jedoch icht, weil sie gelöst worde wäre. Nach 20 Jahre Krise wurde der Magelzustad als Normalität defiiert. Viele Uterehme lebe ach wie vor mit stetig wachsede IT-Koste, ohe dass sich die Leistugsfähigkeit der IT eeswert verbesser würde. Gerade große Firme leiste sich Time-to-Market-Zeiträume, die läger als ei Jahr, teilweise sogar zwei ud mehr Jahre betrage. Gleichzeitig ka ma de Siegeszug der agile Bewegug (vgl. [Wiki-d]) im Bereich der Softwareetwicklug beobachte. Durch diese werde Produkte scheller ud qualitativ hochwertiger hergestellt. Sid die Idee des Software-Egieerigs also ei Irrtum? Ist der IT-Taylorismus gescheitert? Währed die zweite Frage bejaht werde muss, ist die erste Frage icht so eifach zu beatworte. Das Software-Egieerig hat viele Idee, Kozepte ud Techike hervorgebracht, die auch heute och sivoll sid. Allerdigs habe sich die Rahmebediguge seit de frühe 1970er Jahre so grudleged geädert, dass die Idee ud Kozepte des Software-Egieerigs a de heutige Kotext agepasst werde müsse. Startete ma i de späte 1960er Jahre och mit eiem komplizierte Produkt i eiem scheibar ulimitierte Markt, i dem die kosteeffiziete Skalierug der Produktio der treibede Faktor war, existiert heute ei Umfeld, das vo dyamikrobuste Uterehme (vgl. [Woh07]) beherrscht wird ud i dem Reaktiosgeschwidigkeit ud Flexibilität die etscheidede Größe für die IT sid. I der IT erfolgte der Übergag i de späte 1980er ud frühe 1990er Jahre schleiched: Die Leistugsfähigkeit vo IT-Systeme stieg kotiuierlich (vgl. auch Mooresches Gesetz, [Wiki-e]), der Siegeszug der PCs bega ud die Veretzug der Systeme schritt vora. Die Aweduge wurde immer veretzter ud astatt ur puktuell eizele Geschäftsfuktioe IT-seitig zu uterstütze, wurde die Geschäftsseite immer durchgägiger vo der IT uterstützt somit äherte sich die IT immer weiter a die Marktdyamik des Busiess a. Heute ist die IT das Nervesystem der meiste Uterehme. Ohe eie fuktioierede IT ist der Geschäftsbetrieb i der Regel icht mehr möglich ud alle Äderuge auf der Geschäftsseite egal ob es eue oder veräderte Produkte oder veräderte Abläufe sid müsse i de IT- Systeme abgebildet werde. Es hat sich herausgestellt, dass der Taylorismus im Umfeld der IT keie Si ergibt. Aber auch adere Errugeschafte des Software-Egieerigs müsse überdacht werde. Leider werde sie oft ureflektiert verwedet, ohe sie a die gegewärtige Bediguge azupasse. Das tayloristisch motivierte Pla-Build-Ru ist tot. Eiige halte gar de Begriff Software-Egieerig für eie Irrtum (vgl. [Per12]). Aber wie köe die Kozepte a die heutige Aforderuge agepasst werde? Agilität als Wegbereiter Ei wichtiger Schritt zu eiem modere Software-Egieerig ist sicherlich die agile Bewegug. Sie ist i de 1990er Jahre etstade. Die Befürworter der traditioelle Vorgehesmodelle versuchte och immer, die Softwareetwicklug durch immer umfagreichere Rahme- ud Regelwerke zu orgaisiere, ohe die geäderte Bediguge i Betracht zu ziehe. Die Agilität (vgl. [Tho14]) hat eue Wege etwickelt, die besser zu de veräderte Aforderuge passe. Ohe im Detail auf die Etwicklug der agile Bewegug eizugehe, ka aus heutiger Sicht festgestellt werde, dass sie vielfach zu eier zeitgemäßere Firmekultur geführt hat: Es hat eie Rückbesiug vo Verfahre auf de Geschäftswert stattgefude. Etspreched wurde Veratwortlichkeite eu aufgeteilt, z.b. i Form eies Product Owers bei Scrum (vgl. [Wiki-f]) astelle vo Projekt- ud Produktmaager. Die Etwicklugszykle sid deutlich kürzer geworde. Das flexible Reagiere auf geäderte Aforderuge wurde deutlich verbessert. Die Prozessmodelle wurde verschlakt. Die Hierarchie sid i der Regel flacher geworde. Routietätigkeite wurde stärker automatisiert, um mit de schellere Etwicklugszykle besser umzugehe. Zusamme mit eier itesivierte Testautomatisierug führte dies zu eier bessere Softwarequalität. Alle Asätze basiere auf eiem Wertesystem (vgl. [Bec01]), bei dem im Uterschied zum Taylorismus Mesche ud Iteraktioe im Vordergrud stehe. Aber es gibt auch Defizite: Zum eie war der Betrieb bislag auße vor. Agilität wurde ur auf de erste Teil der IT-Wertschöpfugskette vo de Aforderuge bis zum Bau der Software agewedet. Die Treug zwische Etwicklug ud Betrieb existiert immer och. Währed die agile Etwicklug immer scheller ud flexibler Software produziert, ist der Betrieb häufig ach wie vor i de herkömmliche Prozessstrukture gefage (teilweise bis i die Zielvereibaruge des Maagemets hiei). I der Folge verpufft die schelle Umsetzug fachlicher Aforderuge häufig a de Greze zum Betrieb ud aufgrud traditioeller Release-Prozesse ud -Zykle dauert es immer och mehrere Moate, bis eie Aforderug ihre Weg i die Produktio fidet. Im ugüstigste Fall verkommt die Agilität zu eier Art Gruppetherapie für frustrierte Etwickler, die sich a ei weig Scrum erfreue, währed der Rest des Uterehmes wie eh ud je agiert. Außerdem hat die Ausgrezug des Betriebs zur Folge, dass betriebsrelevate Eigeschafte bei der Etwicklug verachlässigt werde. Die Product Ower habe häufig ur Fachaforderuge im Blick, icht-fachliche Aforderuge wie z.b. Robustheit, Überwachbarkeit ud betriebliche Eifachheit werde übersehe. Der Betrieb bekommt immer scheller eue Software über de Zau geworfe, die icht betriebsfertig ist, d.h. für de Betrieb essezielle Aforderuge werde icht umgesetzt. Als Effekt wächst der Widerstad auf Seite des Betriebs, er immt sich och mehr Zeit, die eue Software i Produktio zu ehme, ud die scho seit lagem vorhadee Gräbe zwische Etwicklug ud Betrieb vertiefe sich weiter. DevOps: Agilität zu Ede gedacht Der Begriff DevOps ist im Rahme der DevOpsDays etstade, eier Koferez, die 2009 i Belgie erstmals stattfad (vgl. [Dev09]). Auch we der Begriff das Zusammespiel vo Dev (kurz für Developmet Etwicklug) ud Ops (kurz für Operatios Betrieb) suggeriert, so zeichete sich bei de Vorträge der erste Verastaltug ab, dass DevOps mehr als die Summe vo Dev ud Ops ist. 02/

3 Die Reise ach DevOps: Auf dem Weg zu eier bedarfsgerechte IT beide Theme fast zur gleiche Zeit i der öffetliche Wahrehmug agekomme sid. Bei Cotiuous Delivery geht es tatsächlich primär um die Automatisierug vo Build, Test ud Deploymet mit Hilfe eier geeigete Werkzeugkette. DevOps higege ist im Ker ählich wie Agilität eher ei Wertesystem. Die durch Cotiuous Delivery voragetriebee Automatisierug ist ei wichtiger Teilaspekt, aber DevOps ist wesetlich mehr als Automatisierug. Abb. 2: Die drei Wege des DevOps. Eie allgemei aerkate, abschließede Defiitio vo DevOps gibt es allerdigs bis heute icht. Dies ist aber icht verwuderlich, weil DevOps ählich wie Agilität eher ei Wertesystem als eie klar defiierte Methode oder gar ei Produkt ist. So bilde sich auch immer wieder uterschiedliche Iterpretatioe heraus (siehe ute). I der Commuity habe zumidest die Drei Wege des DevOps (vgl. [Kim]) eie sehr breite Aerkeug als elemetare Bestadteile vo DevOps gefude. Vereifacht bestehe diese aus Folgedem (siehe auch Abbildug 2): Weg 1: Die IT-Wertschöpfugskette wird vollstädig betrachtet ud optimiert, d.h. vo de Aforderuge bis zum Betrieb. Weg 2: Es gibt Feedback-Schleife auf alle Ebee icht ur vo der Etwicklug zu de Aforderuge. Weg 3: Es wird eie Kultur der kotiuierliche Verbesserug basiered auf kotrollierte Experimete aufgebaut. Dieser Aspekt hat ebe der Agilität auch eie Verbidug zu Lea Startup (vgl. [Rie11]). Die Keridee vo DevOps ist es, die Feedback-Schleife auf die gesamte Wertschöpfugskette vo de Aforderuge bis zum Betrieb auszudehe, astatt sie wie bei der Agilität häufig zu beobachte am Ede der Produktetwicklug abzubreche. Damit ist es möglich, die Produktioskette durchgägig zu optimiere, die Durchlaufzeite ud die Flexibilität bis i de Betrieb zu optimiere, ohe die otwedige Stabilität zu kompromittiere, da auch die Aforderuge des Betriebs hireiched Berücksichtigug fide. So gesehe ka ma DevOps auch als Agilität i der IT kosequet zu Ede gedacht betrachte. Missverstädisse Leider stößt ma i der Praxis immer wieder auf Missverstädisse ud Uklarheite rud um das Thema DevOps. Missverstädis 1: DevOps betrifft ur die Zusammearbeit vo Etwicklug ud Betrieb ud ist damit ei reier IT-Selbstzweck DevOps hat vo Afag a die gesamte IT-Wertschöpfugskette ud icht ur das Zusammespiel vo Etwicklug ud Betrieb im Fokus. Nur eie übergeordete Betrachtug der Wertschöpfugskette verschafft ei komplettes Bild der Herstellug vo Software. DevOps versucht dabei icht, alle Dige des erweiterte Fokus eu zu erfide, soder auf dem Wisse aus Agilität ud Lea (vgl. [Pop03]) bis hi zu Lea-Startup aufzusetze. Missverstädis 2: DevOps ist ur die Automatisierug vo Build ud Deploymet Häufig wird DevOps mit Cotiuous Delivery verwechselt möglicherweise weil Missverstädis 3: DevOps beötigt Full Stack Developer Ei sich hartäckig halteder Irrtum aus der Agilität hat leider auch Eizug i DevOps gehalte. Agilität spricht häufig vo cross-fuktioale Teams, also Teams, i dee alle beötigte Fähigkeite i Form etsprecheder Persoe versammelt sid, um die jeweilige Aufgabestellug umzusetze. Team wurde i der Folge aber häufig mit Etwicklerteam gleichgesetzt ud es wird diskutiert, welche Skills Etwickler zusätzlich beötige, astatt zu überlege, welche Persölichkeite i eiem solche Team sivoll mitarbeite sollte, die icht zwagsläufig Softwareetwickler sid. Geau der gleiche Irrtum setzt sich auch im DevOps-Umfeld fort. Dort trägt er de Name Full Stack Developer. Damit ist ei Etwickler gemeit, der vo der Blech-ud-Draht -Ebee bis hi auf die Awedugsebee alles perfekt beherrscht atürlich iklusive der Kofiguratio vo Betriebssysteme, Router, Firewalls usw. Ud die gaze agile Zusatzfähigkeite, wie die perfekte Beherrschug vo Fachdomäe, Aforderugsaalyse ud Architektur, komme atürlich och dazu. Das geht so weit, dass ma de Begriff Full Stack Developer mittlerweile auch scho i Stelleausschreibuge fidet. Kaum jemad ka diese Themevielfalt durchgägig perfekt beherrsche ud der damit aufgebaute Erwartugsdruck macht viele Etwickler sehr zu schaffe. Es ist aber icht das Ziel vo DevOps, Etwickler möglichst schell i de Burout zu treibe (vgl. auch [Ku14]). Natürlich ist es otwedig, dass Etwickler, die sich i eiem DevOps-Umfeld bewege möchte, ihre Blick weite. Es ist wichtig, dass sie verstehe, was die Bedürfisse ud Aforderuge des Betriebsteams sid, damit diese bei der Arbeit berücksichtigt werde köe. Geauso sollte verstade werde, was die Bedürf- 12

4 Abb. 3: Das T-förmige Profil. Abb. 5: Der DevOps-Sweetspot. Abb. 4: Cross-fuktioale Besetzug vo Teams statt Full Stack Developer. isse des Fachbereichs sid. Sie müsse auch eie Vorstellug davo habe, wie der Betrieb fuktioiert, was die Bausteie eier Produktiosumgebug sid, usw. Aber sie müsse das icht alles perfekt köe. Chris Johso hat es sehr schö i eiem Blogartikel zusammegefasst (vgl. [Joh14]): To be a master of aythig, you must uderstad two layers above ad two levels below the layer you re targetig. Ud er fährt fort (der leichtere Lesbarkeit halber hier übersetzt): We ma der beste Javascript-Etwickler werde möchte, sollte ma ei fudiertes Verstädis davo habe, wie der Javascript-Parser fuktioiert ud auch wie Browser fuktioiere. Des Weitere sollte ei guter Etwickler verstehe, welche Eifluss seie Applikatio auf die weitere Ebee oberhalb seies Eiflusses hat. I diesem Kotext ist auch das T-förmige Profil (vgl. [Wiki-g]) relevat (siehe Abbildug 3). Ei Etwickler sollte über ausreiched Breitewisse verfüge, um die Erforderisse ud Bedürfisse aller adere beteiligte Bereiche verstehe zu köe. Das ist auch eie Grudvoraussetzug für eie zielführede Zusammearbeit. Aber seie Kerdomäe ist immer och die Softwareetwicklug, hier hat er sei Tiefewisse. We er i adere Bereiche über zusätzliches Tiefewisse verfügt, ist das erfreulich, aber icht zwiged otwedig. Die zusätzlich beötigte Fähigkeite werde i das Team geholt, idem es cross-fuktioal besetzt wird, im Falle vo DevOps ebe auch mit Betriebsexperte (siehe Abbildug 4). Nicht ur die Schittmege aus dem Domäewisse ud Breitewisse der Teammitglieder sorge dafür, dass das Team die maximale Leistugsfähigkeit hat, soder auch dere soziale Fähigkeite ud Rolle (Katalysator, Experte, vgl. [Joi06]). Aus dieser Schittmege bildet sich da ei DevOps-Sweetspot (siehe Abbildug 5), i dem das Team maximal agiere ka. Missverstädis 4: Literatur & Liks Dev überimmt Ops, d.h. die Etwicklug macht de Betrieb mit Dieser Irrtum hägt eg mit dem zuvor beschriebee Missverstädis zusamme. [Bec01] K. Beck et al., Maifesto for Agile Software Developmet, siehe: [Coc14] A. Cockcroft, State of the Art i Microservices, Dockerco Europe Amsterdam 2014, Vortrag, siehe: [Dev09] DevOpsDays, Ghet 2009, siehe: [Joh14] C. Johso, The broader poit behid robots eatig our jobs, siehe: [Joi06] B. Joier, S. Josephs, Leadership Agility Five Levels of Mastery for Aticipatig ad Iitiatig Chage, Wiley 2006 [Kam14] Kamu, Uitig DevOps ad ITSM, siehe [Kim] G. Kim, The Three Ways: The Priciples Uderpiig DevOps, siehe: [Ku14] J. Kupp, How DevOps is Killig the Developer, 2014, siehe: [NATO] The NATO Software Egieerig Cofereces, siehe: [Per12] P. Perrotta, A short history of Software Egieerig, Baruco 2012, siehe: [Pop03] M. Poppedieck, T. Poppedieck, Lea Software Developmet, Addiso Wesley 2003 [Rie11] E. Ries, The Lea Startup, Portfolio Pegui 2011 [So07] D. Sowde, M. Booe, A Leader s Framework for Decisio Makig, Harvard Busiess Review, 2007 [Tho14] D. Thomas, Agile Is Dead (Log Live Agility), siehe: [Wiki-a] Wikipedia, Softwarekrise, siehe: [Wiki-b] Wikipedia, Fordism, siehe: [Wiki-c] Wikipedia, Taylorismus, siehe: [Wiki-d] Wikipedia, Agile Softwareetwicklug, siehe: [Wiki-e] Wikipedia, Mooresches Gesetz, siehe: [Wiki-f] Wikipedia, Scrum, siehe: [Wiki-g] Wikipedia, T-shaped skills, siehe: [Woh07] G. Wohlad, M. Wiemeyer, Dekwerkzeuge der Höchstleister Wie dyamikrobuste Uterehme Marktdruck erzeuge, Murma-Verlag /

5 Die Reise ach DevOps: Auf dem Weg zu eier bedarfsgerechte IT Abb. 6: IT-Umstrukturierug vo Spezialiste-Silos zu cross-fuktioale Fach-Teams (ach [Coc14]). Um es kurz zu mache: Dev überimmt icht Ops, soder ma kümmert sich i cross-fuktioale Teams gemeisam um die gesamte IT-Wertschöpfugskette für de Teil der Systeme, für die das Team veratwortlich ist. Das setzt aber bei traditioelle Betriebsstrukture ei radikales Umdeke voraus ud führt letztlich zu gaz adere Orgaisatiosstrukture. Ausblick Nach diesem Exkurs zu eiige Missverstädisse vo DevOps bleibt die Frage, wie sich das Thema weiteretwickel wird. Grudsätzlich muss gefragt werde: Hat DevOps eie Zukuft oder ist es eie Modeerscheiug? Da immer wieder eue Begriffe für vermeitlich iovative Kozepte erfude werde, ist atürlich icht klar, ob sich der Begriff DevOps halte wird, aber das, wofür DevOps steht, ist ei essezieller Baustei i der IT der Zukuft. Woher kommt diese Überzeugug? Die Rahmebediguge für die IT habe sich grudleged geädert. Die IT ist das Nervesystem der meiste Uterehme ud somit ohe Eischräkuge de Markterforderisse der Geschäftsseite ausgesetzt. Da es sich häufig um ege, hoch dyamische Märkte hadelt, i dee ur dyamikrobuste Uterehme bestehe, beötige diese eie IT, die sie dabei optimal uterstützt: Neue Idee müsse schell umgesetzt werde, eie flexible Reaktiosfähigkeit ist ei Muss ud die Betriebsstabilität darf dabei icht verachlässigt werde. Diese Aforderuge a die IT köe aber ur umgesetzt werde, we alle a der Wertschöpfugskette Beteiligte zusammearbeite. Darum geht es bei DevOps: Statt Spezialiste-Silos, die vom Gesamtprozess etkoppelt vor sich hiarbeite, werde cross-fuktioale Teams eigesetzt, die auf die Wertschöpfug achte ud diese kotiuierlich verbesser. Damit wadelt sich die IT-Orgaisatio: A die Stelle vo Spezialiste-Silos trete Fachteams, die für ihre Teil der IT-Systeme eie Ed-to-Ed-Veratwortug überehme vo der Aforderug bis zum Betrieb (siehe Abbildug 6). So sage de auch IT-Vordeker wie z. B. Adria Cockcroft: DevOps ist eie Umstrukturierug der IT (vgl. [Coc14]). Ebeso ist bei de Vordeker eie weitergehede Differezierug bezüglich der cross-fuktioale Teams zu beobachte. Abb. 7: DevOps-Weiteretwicklug mit Plattform-Team ud Self-Service-API (ach [Coc14]). 14

6 Ei fehlschlageder Testfall ka durchaus Probleme verdecke, die erst ach Behebug der offesichtliche Ursache zu Tage trete. Ziel des Teams muss es sei, die Testfälle auch währed der Etwicklug grü zu halte. Grü bezieht sich hier auf die Sigalfarbe, die traditioell i Build- Umgebuge eigesetzt werde. Statt Basis-Services wie z. B. Recheleistug, Speicher ud Netzwerk vo jedem Fachteam idividuell verwalte zu lasse, werde diese Dieste vo eiem eiges gehesweise, we die Erweiterug durch dafür abgestellte so geate Plattform- Umpriorisierug doch icht stattfidet ud Team über eie Self-Service-API bereitgestellt (siehe Abbildug 7). die Tests weiterhi mauell durchgeführt werde müsse. Mit wachsedem Reifegrad köe auch Aus userer Erfahrug loht sich eie weitere Dieste sukzessive vom Plattformsprechede, achvollziehbare Zuordug Team bereitgestellt werde, wie etwa Database-as-a-Service oder Message-Queue- vo Aforderuge (User-Storys) ud Akzeptaztests. Wird eie Aforderug as-a-service. Wichtig ist hierbei, dass alle verädert oder erweitert, fließt der Auf - Diestleistuge des Plattform-Teams vo wad für eie otwedige Apassug de Fachteams über eie Self-Service-API besteheder Akzeptaztests mit i die bezoge werde köe. Cockcroft bezeichete dies i [Coc14] sehr plastisch als Schätzug ei. Gibt es außerhalb des Etwicklugsteams Iteressete für die Ops mit eier API. Akzeptaztest-Kriterie, erhalte diese Nebe der Frage ach der weitere ihaltliche Etwicklug des Themas DevOps wertvolles Feedback zu de Auswirkuge der Äderug. Köe Aforderuge ud stellt sich och die, wie das Thema vom Akzeptaztests eiader icht zugeordet Markt aufgegriffe wird. Da gibt es uterschiedliche Etwickluge zu beobach- werde, kommt das böse Erwache bei der Etwicklug: Die Äderuge dauer füf te. I de USA hat DevOps eie deutlich Miute, das Apasse der fehlgeschlagee alte Akzeptaztests zwei Tage. weitere Verbreitug als i Deutschlad. I Deutschlad ist es bislag am stärkste bei Startups ud Startup-ahe Uterehme verbreitet (auch we sich bei ma- Mauelle Tests Mauelle Tests sid auch i agile Pro - chem Startup durchaus die Frage stellt, ob jekte wichtig. Sie schließe die Lücke zwische automatisierte Tests ud aufwädig DevOps dort ur die beschöigede Beschreibug für das Fehle jedweder Art vo oder gar icht automatisiert prüfbare Orgaisatio ist). Aforderuge. Dabei köe mauelle Die traditioelle Uterehme tu sich Tests zeitaufwädig ud fehlerafällig sei. higege och schwer mit dem Thema. Auch i der agile Welt eige Projekt - Wie bei alle größere Veräderuge sid teams dazu, mauelle Tests zu verachlässige, we die Zeit am Ede eier auch beim Thema DevOps Zurückhaltug bis offeer Widerstad zu beobachte ud die Fraktio der Bedeketräger hat sich bereits Tipp formiert: 5: Pair-Testig im UAT. User-Acceptace-Tests sollte dabei ie Ja, durch aber die wie Softwareetwickler ist das mit der durchgeführt werde. UAT mittels Pair-Testig hat Compliace? Ja, sich aber dagege wie passt bewährt. das de Hier führt zum ei IT Service Beutzer Maagemet de UAT durch, (ITSM)? der Etwickler Ja, sitzt aber daebe was ud ist, bekommt we ich direkt gesetzliche wertvolles Feedback erfülle zur muss? Beutzbarkeit seier Auflage Ja, Arbeit. aber Im wie Idealfall bekomme ist dieser Tester ich de der die Zusammearbeit Kude selbst oder ei zwische Mitarbeiter de mit tiefem fachliche Wisse, aber keie weite- Teams hi? re Ketisse über de Quellcode. Tipp 6: Zeitaher UAT. Währed der UAT i der klassische Projektwelt eie abgeschlossee Phase darstellt, bietet es sich i agile Projekte a, umittelbar ach dem Abschluss eier Fuktioalität Nutzer-Feedback eizuhole. Will der Etwickler i Folge des Marcel Feedbacks Wolf Äderuge vorehme, ist (marcel.wolf@codecetric.de) seie Arbeit effektiver als ach eiem arbeitete i wechselde Rolle ierhalb der IT. UAT-Feedback mehrere Woche. Aktuell ist er als Seior System Cosultat bei der codecetric AG tätig. Seie Schwerpukttheme sid Cotiuous Delivery, Dataceter Automatio, Ei agile Fokus Softwareetwicklug des UAT liegt auf ud DevOps. der Istal - lierbarkeit der Software. Diese lässt sich leicht i Kombiatio mit der obe beschriebee automatisierte Prüfug auf Kamu: Uitig DevOps ad ITSM (vgl. Vollstädigkeit awede: We dieser [Kam14]). Smoke-Test erfolgreich war, ließ sich die De Bedeketräger sei aber gesagt: Es ist Software offebar erfolgreich istalliere. wesetlich eifacher ud auch bequemer, Ziel des UAT ist es, die Beutzbarkeit eier ach Grüde zu suche, warum DevOps Software zu prüfe. Aus eigeer Erfahrug icht fuktioiere ka, als sich zu überlege, wie eie Umsetzug vo DevOps wisse wir, dass für eie erfolgreiche UAT i alle Teststufe gewissehaft gearbeitet kokret zu gestalte wäre. Aber Fakt ist: werde muss. Für Et wickler gibt ichts Die Rahmebediguge, uter dee das Schlimmeres als eie UAT, der vo de klassische Software-Egieerig etstade sid, existiere i dieser Form icht Tester oder vom Kude ach weige Miute abgebroche wird, weil viele offesichtliche Fehler i de vorherige Teststufe mehr. Trotzdem bestimme die darauf aufbauede veraltete Prizipie och immer icht etdeckt wurde ud der Software die meiste IT-Orgaisatioe. Die IT muss magelde Qualität bescheiigt wird. sich a die veräderte Rahmebediguge apasse ud DevOps ist ei wichtiger Last ud Performace-Tests Baustei auf dem Weg dahi. Die Teststufe Last- ud Performace-Tests diet im Wesetliche dazu, drei ichtvo Tests, Fehler i der Software zu fide. We automatisierte Tests dazu ur bedigt i der Lage sid, gibt es lediglich eie Alterative: mauelles beziehugsweise exploratives Teste, bei dem die Tester ihre Kreativität ud Spotaität eisetze, um Fehler zu fide. Ei wesetlicher Nutze Die maueller Autore Tests besoders bei eue Features ist die kotextbezogee Perspektive auf die zu prüfede Fuktioalität. De im Gegesatz zu automatisierte Tests ket der mauelle Tester dere aktuelle Kotext. We es Kude ud Budget zulasse, plae wir am Ede eier Iteratio für alle Etwickler eie Tag ei, desse Fokus auf maueller Testdurchführug liegt. Ziel dieses Tages ist es, die Software zerbreche zu lasse. Uwe Friedrichse Geligt es, de Code durch Beut - zer (uwe.friedrichse@codecetric.de) eigabe oder Datekostellatioe zu ist ei lagjähriger Reiseder i der IT-Welt. Als zerbreche, wird für die Situatio, die dazu Fellow der codecetric AG ist er stets auf der geführt hat, ei automatisierter Test Suche ach iovative Idee ud Kozepte. geschriebe. Seie aktuelle Aschließed Schwerpukttheme wird sid der Skalierbarkeit, ach Resiliece voll ziehbar ud behobe die IT vo (über)morge. ud mit dem Ma - gel automatisierte Test dafür gesorgt, dass die so ge woee höhere Robustheit erhalte bleibt. Ja, aber da werde ich doch icht alle Mitarbeiter mitehme köe. Plädoyer für Nicht- Automatisierug Die Liste der Grüde, warum DevOps ageblich icht fuktioiere ka, ist lag. We die geforderte Fuktioalität implemetiert wurde, also sämtliche automatisierte Tests durchgeführt ud um evetuell Hier wird auch icht behauptet, dass die Eiwäde ubegrüdet sid oder Frage otwedige mauelle Tests der eue icht gestellt werde dürfe. Der Wadel ist icht trivial ud es müsse och Features ergäzt wurde, schließt sich eie weitere mauelle Stufe a. viele Herausforderuge auf dem Weg zu Der User-Acceptace-Test (UAT) diet DevOps als akzeptierte Struktur agegage werde. Viele sivolle Ziele (die dazu, eie Software uter reale Bedi gu - ge zu teste ud zu prüfe, ob eie Ziele vo ITSM sid z.b. durchaus sivoll) müsse uter de geäderte Afor- Software effiziet ud effektiv geutzt werde ka. Software, die für Edaweder deruge a die IT eu überdacht ud mit gedacht ist, muss bei dieser Testart vom etspreched agepasste Maßahme uterlegt werde. Asätze zu diesem Thema Beutzer selbst geprüft werde. Dazu ist es otwedig, de fachliche Kotext der zu fidet ma z.b. i der Google+-Gruppe: prüfede Soft ware zu kee ud eizu- OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de die Vollstädigkeit der Fuk tio alität oberflächlich prüfe. Gele getlich werde automatisierte GUI-Tests (Graphi cal-user- Iterface) als UAT bezeichet. Diese Tests sid fuktioale Tests uter Eibeziehug eier Oberfläche ud köe zum Beispiel im Regressiostest eie wertvolle Beitrag leiste. Sie sid aber kei Er satz für die Eibeziehug des Mesche als Tester. 4 / /