DevOps_TitelbildSoft­ware entwick­eln und dynamisch in den sta­bilen Betrieb über­führen – das ist, wofür die DevOps-Strate­gie ste­ht. Dabei han­delt es sich um eine „End-to-End-Strate­gie“, die stark an die Prinzip­i­en der agilen Organ­i­sa­tion eines Unternehmens erin­nert. Anders als die agile Organ­i­sa­tion selb­st ist DevOps aber auss­chließlich für die Soft­wa­reen­twick­lung und den Soft­ware­be­trieb gemacht. Was genau sich dahin­ter ver­birgt, erfahren Sie in dieser Lek­türe.

Dieser Artikel ist geeignet für: Jeden, dessen Arbeit nach den Prinzip­i­en von DevOps organ­isiert ist und der – ins­beson­dere als Soft­wa­reen­twick­ler oder Admin­is­tra­tor – Input zu Opti­mierungspoten­zialen sucht. Dieser Artikel ist auch zu empfehlen, wenn Sie nicht mit DevOps arbeit­en, sich aber ein Grund­wis­sen dazu aneignen möcht­en.

Schwierigkeits­grad:*1234

*Weite Teile des Artikels sind ohne Grund­wis­sen ver­ständlich. Um aber die Schnittstellen, ins­beson­dere zu den Meth­o­d­en des agilen Pro­jek­t­man­age­ments einord­nen zu kön­nen, ist ein entsprechen­des Grund­ver­ständ­nis dessen hil­fre­ich. Wir empfehlen unsere Lek­türe zum agilen Pro­jek­t­man­age­ment mit Scrum.

DevOps in Kürze + Definition

 

  • Def­i­n­i­tion: DevOps ist eine Arbeit­sor­gan­i­sa­tion in der Soft­wa­reen­twick­lung, welche den Entwick­lung­steil direkt mit dem Betrieb­steil verbindet und so diverse Vorteile liefert.
  • Bei DevOps wer­den die Spezial­is­ten aus Soft­wa­reen­twick­lung und ‑betrieb zur direk­ten Inter­ak­tion ver­bun­den, wodurch die einen jew­eils die Erwartun­gen der anderen ken­nen. Außer­dem sind stets Prozes­sop­ti­mierun­gen mit ein­er hohen Mess­barkeit sowie der Ein­satz von inno­v­a­tiv­en Tools und Werkzeu­gen vorge­se­hen.
  • Es gibt bei DevOps kein 100% strin­gentes Konzept, aber drei Eckpfeil­er, die von zen­traler Bedeu­tung sind – näm­lich die Par­a­dig­men der agilen Organ­i­sa­tion und das agile Man­i­fest sowie die Prozes­sop­ti­mierun­gen und inno­v­a­tiv­en Werkezuge.
  • Als Pro­jek­t­man­age­ment-Meth­o­d­en kom­men in DevOps über­wiegend Scrum und Kan­ban zum Ein­satz – auch wenn dazuge­sagt wer­den muss, dass man bei Scrum eine Extram­eth­ode braucht, weil das Frame­work nur den Entwick­lung­sprozess (als Pro­jekt) und nicht den Betrieb von Soft­ware abbildet.
  • Es gibt keine definierten Akteure in DevOps – eher beste­hen die Teams aus den bekan­nten Rollen, die sich in den Bere­ichen der Soft­wa­reen­twick­lung und des Soft­ware­be­triebs wiederfind­en lassen. Gegebe­nen­falls emp­fiehlt es sich, einen davon unab­hängi­gen Meth­o­d­en­ex­perten einzu­binden, der die Ein­hal­tung der all­ge­meinen Richtlin­ien von DevOps überwacht.

Warum ist die Arbeitsorganisation nach DevOps sinnvoll?

DevOps_AdministratorIns­beson­dere im Hin­blick darauf, dass der Betrieb­steil ein­er Soft­ware schon während der Entwick­lung eine Rolle spielt, ist DevOps für die meis­ten Unternehmen im Soft­wa­reen­twick­lungs­bere­ich sin­nvoll. Schon bei der erst­ma­li­gen Entwick­lung von Soft­ware und bei neuen Ver­sio­nen wird der spätere Betrieb­saspekt mit ein­be­zo­gen. So ist beispiel­sweise eine gut organ­isierte und schnelle Über­führung der Soft­ware aus dem Entwick­lungs­bere­ich in den Betrieb­s­bere­ich sichergestellt. Eine hohe Betrieb­ssta­bil­ität sowie eine gute Wart­barkeit wer­den zu wichti­gen Kri­te­rien bei der Beurteilung der Pro­duk­tion­sreife. Sie sind Grund­vo­raus­set­zung für die Ein­führung ein­er neuen Soft­ware oder ein­er Soft­ware­ver­sion.

Gibt es konkrete Unterschiede zur normalen Organisation anstelle von DevOps?

In Soft­ware­un­ternehmen, die DevOps nicht anwen­den, ist der Soft­ware­be­trieb für gewöhn­lich von der Soft­wa­reen­twick­lung getren­nt. Bei­de Bere­iche arbeit­en in ihrer straf­fen Organ­i­sa­tion an ihren Auf­gaben, haben aber bis auf die konkrete Soft­wareüber­führung keine gemein­samen Verbindun­gen. Bei DevOps ver­schmelzen die Teams dage­gen, ver­gle­ich­bar mit der Grund­struk­tur ein­er agilen Organ­i­sa­tion. Das bedeutet, dass nicht mehr zwei strikt voneinan­der getren­nte Abteilun­gen für den jew­eils einen und anderen Bere­ich existieren, son­dern dass die jew­eili­gen Spezial­is­ten aus bei­den Bere­ichen in einem Team zusam­me­nar­beit­en. Sie inter­agieren direkt miteinan­der und tauschen sich aus. Die Entwick­ler wis­sen, worauf es den Betreibern ankommt und ander­sherum.

Bei DevOps sind zudem stetige Prozes­sop­ti­mierun­gen durchzuführen. Das Ziel ist, bessere Soft­ware mit umfan­gre­icher­er Funk­tion­al­ität in kürz­er­er Zeit herzustellen. Es kommt eben­falls zu ein­er schnelleren Tak­tung der Soft­ware­ver­sio­nen, also zu kürz­eren Releasezyklen. Zur Erre­ichung der genan­nten Ziele wer­den inno­v­a­tive Tech­nolo­gien und Werkzeuge einge­set­zt. Die qual­i­ta­tiv­en und quan­ti­ta­tiv­en Verbesserun­gen sind durch zen­trale Kenn­zahlen (Key Per­for­mance Indi­ca­tors = KPIs) zu messen und trans­par­ent zu machen. Auf der Basis objek­tiv­er Fak­ten wird eine kon­tinuier­liche Verbesserung angestrebt. Das gibt es in klas­sisch organ­isierten Soft­ware­un­ternehmen eben­falls nicht.

Kurzum bringt DevOps mehrere prinzip­iell unab­hängige Konzepte zusam­men:

  • Zusam­me­nar­beit von Entwick­lung und Betrieb in ein­er agilen Organ­i­sa­tion mit dem dafür typ­is­chen kul­turellen Wan­del im Unternehmen
  • Par­a­dig­men / Kul­tur der agilen Soft­wa­reen­twick­lung (meist mit den Meth­o­d­en von Scrum und mit Min­i­mum Viable Prod­ucts)
  • Effizien­zsteigerung von Prozessen mit hoher Mess­barkeit dieser
  • Ein­satz von inno­v­a­tiv­en Tech­nolo­gien und Werkzeu­gen

Wie sieht die Funktionsweise von DevOps aus?

Sehen Sie sich ver­schiedene Quellen an, dann wer­den Sie schnell fest­stellen, dass jede das DevOps-Konzept ein wenig anders beschreibt. Dem­nach scheint es nicht ein 100% strin­gentes Konzept zu geben. Wohl gibt es bei DevOps aber drei grund­sät­zliche Eckpfeil­er, die als Qua­si-Stan­dard beze­ich­net wer­den kön­nen.

Paradigmen aus der agilen Organisation

Agile Organ­i­sa­tio­nen zeich­nen sich durch  Merk­male aus, die auch hier eine tra­gende Rolle spie­len. Das bedeutet im ersten Schritt, dass alle an der Soft­wa­reen­twick­lung und am Soft­ware­be­trieb Beteiligten in einem gemein­samen Team arbeit­en. Das entste­hende Team ist nach dem „End-to-End-Prinzip“ für die Soft­ware ver­ant­wortlich. Als Arbeit­sergeb­nis ste­hen immer am Markt ver­w­ert­bare Soft­ware­pro­duk­te im Fokus. Hier­ar­chien gibt es bei der Ergeb­nis­er­ar­beitung keine, genau­so keine Ein­flussnahme von anderen Organ­i­sa­tion­sein­heit­en. Stattdessen weist jedes einzelne Team­mit­glied einen hohen Grad an Selb­stor­gan­i­sa­tion und Selb­stver­ant­wor­tung auf. Die DevOps-Organ­i­sa­tion­sein­heit sollte ide­al­er­weise nicht mehr als zehn Leute umfassen. So ist eine ein­wand­freie Zusam­me­nar­beit durch Selb­stor­gan­i­sa­tion gegeben. Weit­ere rel­e­vante Par­a­dig­men agiler Organ­i­sa­tio­nen kön­nen Sie in diesem ver­tiefend­en Artikel nach­le­sen.

Agiles Manifest als Ausrichtungsgrundlage

Abge­se­hen von der agilen Organ­i­sa­tion, verpflichtet sich DevOps auch grund­sät­zlich dem agilen Man­i­fest. Das Man­i­fest definiert Werte, die bei der Entwick­lung von Soft­ware und bei deren Bew­er­tung zu berück­sichti­gen sind. Vere­in­facht beschrieben, ist das agile Man­i­fest ein in vier Eckpfeil­ern for­muliertes Wertesys­tem:

  • Indi­viduen und Inter­ak­tio­nen ste­hen über Prozessen und Tools
  • Funk­tions­fähige Soft­ware ist wichtiger als eine Soft­ware-Doku­men­ta­tion
  • Eine Zusam­me­nar­beit mit dem Kun­den und die Berück­sich­ti­gung seines Feed­backs sind von großer Bedeu­tung
  • Auf Verän­derun­gen ist schnell und effizient zu reagieren

Es geht darum, diese agilen Grundw­erte des Man­i­fests bei der täglichen Arbeit der Soft­wa­reen­twick­lung zu leben und zu konkretisieren. Sämtliche Prozesse, Organ­i­sa­tio­nen und Werkzeuge müssen sich hier­an ori­en­tieren.

Prozessoptimierungen und innovative Werkzeuge

Im Rah­men von DevOps wer­den die wesentlichen Abläufe hin­sichtlich zen­traler Kenn­zahlen wie Durch­laufzeit­en, Fehler­rat­en und Kapaz­itäts­bindung stetig weit­er­en­twick­elt. Zusät­zlich wer­den inno­v­a­tive Werkzeuge zur weit­eren Verbesserung einge­set­zt. Diese Prozes­sop­ti­mierun­gen, inno­v­a­tiv­en Werkzeuge sowie weit­ere typ­is­cher­weise im Zuge von DevOps angewen­de­ten Meth­o­d­en sind Gegen­stand des näch­sten Abschnitts.

Welche Methoden und Tools sind unter DevOps empfohlen?

DevOps_Designer_

Methoden in DevOps

Typ­is­che Meth­o­d­en, die im Rah­men von DevOps einge­set­zt wer­den, sind Scrum und Kan­ban. Wobei Scrum genau genom­men als Pro­jek­t­man­age­ment-Frame­work und nicht als Meth­ode zu beze­ich­nen ist. Wichtig ist zu beto­nen, dass keine der genan­nten und auch keine anderen Meth­o­d­en im Rah­men von DevOps expliz­it vorgeschrieben oder genan­nt sind. Die Organ­i­sa­tionein­heit bes­timmt autark, wie und mit welchen Tools und Werkzeu­gen sie ihre Ergeb­nisse erar­beit­et. Scrum und Kan­ban sind als die bekan­ntesten agilen Pro­jek­t­man­age­men­tan­sätze ein­schließlich der typ­is­cher­weise in diesem Zusam­men­hang einge­set­zten „Unter­meth­o­d­en“ (etwa das Pla­nungspok­er bei Scrum) empfehlenswert. Obwohl man beto­nen muss, dass Scrum nur auf die Neu- und wesentliche Weit­er­en­twick­lung einzel­ner Pro­duk­tinkre­mente aus­gerichtet ist – also nur auf den Entwick­lung­steil der Soft­ware – und dass für den Betrieb­steil daher noch eine weit­ere Meth­ode erforder­lich ist. Das kann eine stan­dar­d­isierte  oder auch eine Indi­vidu­elle sein. Kan­ban ist wiederum für bei­de Teile von DevOps gut geeignet und erfordert keine Zweit­meth­ode.

Tools und Werkzeuge in DevOps

Neben den Pro­jek­t­man­age­men­tan­sätzen kom­men noch Tools und Werkzeuge ins Spiel, die etwa bei der Inbe­trieb­nahme der Soft­ware einge­set­zt wer­den. Hier beste­ht im Fokus ein enormer Mehrw­ert. Fokussieren Sie sich auf einige wenige Tools und Werkzeuge und wen­den Sie diese mit hoher Effizienz an. Geht es um die Auswahl neuer Tools und Werkzeuge, dann geht es zuerst um die Frage, was man bei der Entwick­lung der Soft­ware oder bei deren Betrieb grundle­gend verbessern möchte. Auf Grund­lage dessen wird entsch­ieden, welche Deploy­ment-Tools, Release­m­an­age­ment-Tools, Soft­ware-Test­tools und anderen Werkzeuge in Zukun­ft einzuset­zen sind. Dabei gilt eine Maxime: Entschei­den Sie sich für einen der Mark­t­stan­dards. Denn hier gibt es laufend Soft­ware-Updates, umfassende Doku­men­ta­tio­nen und vor allem viel Per­son­al, das sich damit ausken­nt. Klare Empfehlun­gen für Tools und Werkzeuge wer­den nicht ange­sprochen.

Technologien in DevOps

Con­tainer­isierung von Anwen­dun­gen: Con­tain­er sind tech­nol­o­gisch voll­ständi­ge Umge­bun­gen für den Betrieb und die Entwick­lung von Anwen­dun­gen. Sie vere­inen die IT-Ser­vices wie Rechen­leis­tung, Vir­tu­al­isierung und Betrieb­ssys­tem. Im Gegen­satz zur Vir­tu­al­isierung ist Con­tainer­isierung auch gut für Entwick­lungssys­teme geeignet und ermöglicht eine flex­i­blere Kon­fig­u­ra­tion des Betrieb­ssys­tems. Ein Beispiel für einen Con­tain­er ist Dock­er, was neben dem Betrieb­ssys­tem auch noch eine Entwick­lung­sumge­bung bere­it­stellt. Automa­tisierte Test­tools und automa­tisiertes Deploy­ment: Automa­tisierte Test­tools ermöglichen dif­feren­zierte und effizien­tere Soft­waretests. Anstel­lle in Tools, kön­nen die Tests auch auf Codeebene erfol­gen. Zudem sind Tests einzel­ner Kom­po­nen­ten sowie deren kor­rek­ten Zusam­men­wirkens denkbar. Beim Deploy­ment soll eine exzel­lente Lösung in den Betrieb überge­hen. Die automa­tisierten Tests helfen dabei, Fehlerquellen sofort zu ent­deck­en und zu beheben. Beim Deploy­ment selb­st eignen sich Automa­tisierun­gen eben­falls. Sie über­führen Soft­ware­up­dates schnell in die gewün­schte Umge­bung. Ein Beispiel für eine in diesem Zusam­men­hang häu­fig einge­set­zte Tech­nolo­gie ist Jenk­ins. Auch automa­tisierte Release­m­an­age­ments, Orches­tra­tio­nen und Mon­i­tor­ings sind denkbar.

BEST PRACTISE

KPIs und Wirtschaftlichkeit spie­len bei DevOps eine zen­trale Rolle. Aus diesem Grund soll­ten Sie zumin­d­est einige der inno­v­a­tiv­en Tech­nolo­gien ein­set­zen. Zusät­zlich besitzen Opti­mierun­gen zen­traler Soft­wa­reen­twick­lungs- und Betrieb­sprozesse eine wichtige Bedeu­tung. Stets ist die Pro­duk­tiv­ität und der Fortschritt zen­traler Prozesse zu messen und weit­erzuen­twick­eln. Soll­ten die Mess­werte schlecht aus­fall­en, ist zu über­legen, ob DevOps tat­säch­lich eine gute Herange­hensweise in Ihrem Unternehmen ist beziehungsweise wo noch etwas wesentlich zu verän­dern ist. Neben­bei nimmt dadurch ganz automa­tisch auch die Qual­ität der Soft­ware zu.

Wer sind die Akteure bei DevOps?

Bes­timmte Rollen und Akteure wer­den in DevOps nicht expliz­it benan­nt. Es sind alle Mitar­beit­er im Team zusam­men­z­u­fassen, die sich mit der Entwick­lung und mit dem Betrieb von Soft­ware beschäfti­gen. Das kön­nen fol­gende Pro­file sein:

  • Soft­ware-Inge­nieure
  • Soft­wa­reen­twick­ler
  • Soft­waretester
  • Soft­ware-Admin­is­tra­toren
  • IT-/So­lu­tions-Architek­ten
  • Daten­bank-Admin­is­tra­toren
  • Sup­port-/Helpdesk-Mitar­beit­er
  • „Angren­zende Pro­file“ wie etwa IT-Sicher­heits- und Net­zw­erk­ex­perten

Ähn­lich wie bei Scrum mit dem Scrum Mas­ter (Über­sicht zu allen Scrum-Akteuren) ist es sin­nvoll, zumin­d­est zu Beginn, einen Meth­o­d­en­ex­perten einzu­binden, der sich mit DevOps im Detail ausken­nt und das Team in die Organ­i­sa­tions­form hinein­lotst. Der Meth­o­d­en­ex­perte hat die grund­sät­zliche Auf­gabe, die im Rah­men von DevOps anzuwen­den­den Regeln festzule­gen, das Team mit ihnen ver­traut zu machen sowie zu überwachen, dass die Regeln einge­hal­ten wer­den.

Fazit

Sofern Sie DevOps kon­se­quent ein­set­zen, zahlt sich die Organ­i­sa­tion­sstrate­gie im Bere­ich der Soft­wa­reen­twick­lung typ­is­cher­weise voll und ganz aus. Die Grundziele beste­hen in der schnelleren Entwick­lung von Soft­ware-Releas­es, besser­er Soft­ware-Funk­tion­al­ität sowie der Betrieb­sop­ti­mierung dieser Soft­ware. Geeignet ist DevOps allerd­ings nur dann, wenn sich die Soft­wa­reen­twick­lung in viele, agil zu erar­bei­t­ende Releas­es aufteilen lässt. Bei Soft­ware, die wenige und stark zu kon­trol­lierende Releas­es erfordert – so wie es beispiel­sweise bei Finanz­soft­ware oder Luft­fahrt­soft­ware der Fall ist – eignet sich DevOps häu­fig nicht oder es eignen sich nur einige Teil­bere­iche hier­von. Denn diese Arten von Soft­ware erfordern eine hohe Plan­barkeit, das Ergeb­nis muss eine hohe Kon­stanz und Fehler­frei­heit aufweisen. Bei den let­zt­ge­nan­nten Soft­ware­typen herrscht sog­ar eine Null-Fehler­tol­er­anz. Eine Null-Fehler­tol­er­anz ist mit einem agilen Prozess nicht erfüll­bar. Von daher soll­ten Sie in diesem Fall von DevOps abse­hen.