DevOps

DevOps – Wir wollen alle dasselbe!

DevOps, ein neues Buzzword das viele Unternehmen beschäftigt. Viele denken: „Schon wieder etwas Neues! Erst Agile, dann Continuous Integration gefolgt von Continuous Delivery, und jetzt noch DevOps“. Ich kann es vollkommen nachvollziehen, dass in der Flut der Buzzwords, die pro Jahr auftauchen, eine gewisse Ermüdung stattfindet. Dieser Blogbeitrag soll dabei helfen das Thema aus Sicht der Projektleitung zu beleuchten – und das realitätsbezogen und ehrlich. Allerdings muss ich vorwarnen: Wer in diesem Artikel technische Tiefe sucht, sucht leider vergebens.

Der Begriff DevOps setzt sich simpler Weise aus den Begriffen Development und Operations zusammen, unterstützt von automatisierten Qualitätssicherungsprozessen. As simple as that. Doch warum wurden diese zwei Begriffe zu einem verschmolzen? Hat nicht schon jeder für sich genug Arbeit und Aufgaben, die erledigt werden müssen? Die Antwort, wie so oft, lautet: Ja und Nein. Vielleicht hilft ein praxisnahes Beispiel den Knoten der Verwirrung meiner nicht eindeutigen Aussage zu lösen.

devops_pieces-of-the-puzzle_740x415

Alte Muster

Als Projektleiter – vor allem als IT Projektleiter – steht man ganz am Anfang des Projekts vor der Entscheidung, welche Ressourcen eingesetzt werden sollen. Schnell ist einem klar, dass unterschiedlichste Rollen in einem Entwicklungsprojekt benötigt werden, um es über die Ziellinie zu schaffen. Mit der Prämisse, die Anforderungen der Projektauftraggeber, sowie der Stakeholder, ergo das magische Dreieck, zu erfüllen, setzen wir unser Projekt auf. Wer sollte nun im Kernteam sein? Machen wir uns also eine Checkliste:

  • Anforderungsmanager (am besten direkt aus dem Fachbereich)
  • Lösungsarchitekt (am besten einer, der über alle involvierten Systeme Bescheid weiß)
  • Entwickler (natürlich, wir benötigen genau die, die Systeme schon kennen)
  • Tester (wegen der Komplexität und dem Qualitätsgedanken muss manuell, sowie automatisiert getestet werden)

Sehr gut. Dann hätten wir also so gut wie alle. Moment, da fehlt ja noch jemand: der Betrieb oder mit Hilfe von einem Anglizismus:

Operations!

Natürlich – irgendwer muss ja das Ding letztendlich zum Laufen bringen und am Leben erhalten. Aber müssen sie gleich im Kernteam dabei sein. Nein, oder? Sie setzen ja die hochqualitativ, getestete und abgenommene Software in Produktion, also wozu sie jetzt schon belästigen?

Und genau da liegt der Denkfehler. In meinen Projekten bestehe ich darauf, dass der Betrieb von Anfang an mit an Board ist. Oft ist dies leider nicht der Fall, und viele Projekte wundern sich dann gegen Ende, warum „es mit der Kommunikation nicht passt“. Bislang habe ich mit dem frühen Miteinbeziehen durchgängig sehr gute Erfahrungen gemacht. Natürlich muss der Betrieb nicht bei jedem Termin dabei sein, genauso wenig wie die Entwickler oder Tester oder in weiterer Folge auch das Anforderungsmanagement. Was ich damit sagen will: nur, weil der Betrieb die Software nach den alten Denkmustern live nimmt und sie danach betreut, heißt es noch lange nicht, dass man immer laufend in allen Meetings sitzen muss. Dies betrifft auch alle anderen beteiligten Abteilungen im Projekt.

Was hat das jetzt genau mit DevOps zu tun werden Sie sich fragen? DevOps geht noch einen Schritt weiter. Im Laufe meiner Projekte war es meistens so, dass der IT Projektleiter mit dem zugewiesenen Software Architekten die betriebliche Seite abfängt. Der Projektleiter auf organisatorischer, sowie terminlicher Ebene, und der Architekt auf technischer Ebene. Sie bilden also eine Schnittstelle zwischen der Entwicklung und dem Betrieb. Sobald Fragen auftauchen wenden sich die Entwickler an diese Personen und nicht direkt an den Betrieb. Der Mittelsmann wendet sich danach an Operation. Werden Fehler in einem Deployment gefunden geht es postwendend wieder über dieselbe Schiene zurück. So wie immer.

 

Es geht auch anders!

Die Fragen, die dabei nun aufkommen lauten: „Wieso benötigt es einer Schnittstelle? Der Betrieb spielt doch die Software von den Entwicklern ein? Wenn Fehler auftreten, dann muss doch der Betrieb via Logfiles die Analyse durchführen und dann direkt an die Entwickler zurückspielen? Sollte nicht die Entwicklung auf Grund dieser Punkte näher mit dem Betrieb zusammenarbeiten?“ Sie sehen wo es hinführt. Diesmal ist die Antwort auf alle Fragen recht einfach: Ja, natürlich wäre es wichtig, dass die Entwicklung direkt mit dem Betrieb spricht. Aber wieso sollte sich das ändern? Meine Antwort steht schon im Titel dieses Blogartikels:  wir alle wollen dasselbe, effiziente und effektive Vorgehensweisen. Und seien wir mal ehrlich, falsche Arroganz oder Platzhirschverhalten hat noch kein Projekt ans Ziel gebracht.

In meinem Intro schrieb ich, dass das Thema in diesem Artikel weniger technisch beschrieben wird. Dennoch möchte ich auf ein paar technische Aspekte referenzieren. Viele Firmen haben genau das oben angeführte Verbesserungspotential erkannt, und versucht mit diversen Tools bzw. Toolchains die Zusammenarbeit zwischen Entwicklung und Betrieb stärken. Und wissen Sie was? Es funktioniert! Nehmen wir uns als Beispiel Continuous Integration und Delivery. Wird dies gelebt, bekommt die Softwareentwicklung einen hochgradigen Automatisierungsgrad. Die Releases werden immer kürzer und handlicher, und folglich auch überschaubarer. Dies schlägt sich in verbesserter Time to Market Aktivitäten nieder, sowie durch die Zufriedenheit aller Beteiligten. Und mit „allen“ meine ich vom Mitarbeiter bis zum C-Level. Klingt nach einer Winn Situation, meinen Sie nicht?

 

Laufende Tätigkeiten

Falls Ihnen die Begriffe Continuous Integration und Continuous Delivery bislang nichts sagen, würde ich in diesem Absatz ein wenig oberflächlich darauf eingehen. Wer diese Begriffe bereits nicht mehr hören kann, kann gerne zum nächsten Absatz springen.

Um es kurz zu halten: Der Begriff Continuous Integration (CI) beschreibt es in sich schon recht gut, die Durchführung einer kontinuierlichen Integration. Hierfür werden viele Hilfsmitteln zur effizienten und nachvollziehbaren Vorgehensweisen herangezogen. Dabei handelt es sich um leichtgewichtige Kollaborationsentwicklungstools, automatisierte Testvorgänge, saubere Codeversionierungen und daraus resultierende Reports, die allem das Leben leichter machen. Continuous Delivery (CD) ist dann eine auf CI basierende erweiterte Vorgehensweise, welche die Inbetriebnahme (Deployments) der Software oder Teile dieser erleichtern. Die Packages werden zu einem hohen Grade in diverse Systeme eingespielt und davor oft in der Nacht automatisiert regressionsgetestet, damit keine produktionsgefährdeten Fehler mehr auftreten. Wie Sie also erkennen können, beschreiben diese Vorgänge schon eine hochgradige Automatisierung, von dem die Entwicklung, die Qualitätssicherung, sowie der Betrieb profitieren.

Um dies nun zu gewährleisten ist also eine, ich würde fast sagen, „nahtlose“ Zusammenarbeit zwischen Entwicklung und Betrieb notwendig. Ohne DevOps wird CI und CD relativ wirkungs- und erfolglos bleiben.

 

Die Zeiten ändern sich – Neue Methoden braucht das Land

„Wieso sollten die Ansätze ohne DevOps erfolglos sein? Wenn die Entwickler und der Betrieb jeweils für sich ihre Tools beherrschen, wird es dennoch effizienter und es erfolgt wie gehabt eine Übergabe der Software?“ Dies ist nicht ganz richtig, da dieses Prinzip nur dann schlagkräftig wird, wenn man nach agilen Prinzipien vorgeht.

Verstehen Sie mich nicht falsch, der Artikel soll zu keiner Ode an die Agilität in Softwareprojekten ausarten. Dennoch muss angemerkt werden, dass sich die Art und Weise wie Software konzipiert, entwickelt und produktiv gesetzt wird stark geändert hat. Es gibt keine „Hard Cuts“ mehr, es fließt alles ineinander. Jetzt wird der eine oder andere sagen: „Ja aber wir machen seit Jahrzehnten erfolgreich klassische Softwareentwicklung mit dem Wasserfallmodell: Anforderungen, Entwicklung, Test und danach Produktionssetzung“. Subjektiv kann dies stimmen, jedoch ist es eine Tatsache, dass sich die Projekte verzögern, mehr kosten oder sich der Inhalt ändert. Im Worst Case wird eine Software geliefert, die am Markt nicht mehr benötigt wird. Einer der wesentlichen Punkte dabei ist die ewige Suche nach Fehlern oder die Menge an Software, die am Markt laufend zur Verfügung gestellt wird. Heutzutage gibt es viele Anbieter, endlose Substitutionsprodukte und laufend neue Ideen, die schnell implementiert werden müssen, um auf dem Markt Fuß zu fassen. Alles ist schnelllebiger, und das Interesse an einer Software erlischt rascher, als die Unternehmen reagieren können. Bleibt man bei seinen alten Gewohnheiten wird man heutzutage sogar auf der rechten Spur überholt. Deshalb gibt es neue Arten Software zu entwickeln. Der Zeitfaktor spielt dabei eine immer größere Rolle. Oder wollen Sie nicht einer der Ersten sein, der ein Produkt und eine neue Idee hochqualitativ auf den Markt bringt? Jetzt höre ich eine Stimme aus den hinteren Reihen: „Egal ob CI, CD, DevOps, … Fehler gab es immer und wird es weiterhin geben, also was bringt uns das Ganze hier überhaupt?“.

Die Antwort ist leicht: mit dem DevOps Ansatz haben wir vielleicht genauso viele Fehler, wir erkennen sie aber viel früher, beheben sie schneller und effizienter, und reduzieren somit die Gesamtdurchlaufzeit drastisch. Darüber hinaus werden mühsame manuelle Tests fast vollends automatisiert. Dies spart wiederum Zeit. Mit Hilfe von Service Virtualisierung gelingt eine simple Abbildung ganzer heterogener Systemlandschaften, um frühzeitige Tests schnell und produktionsnah durchzuführen. Ebenso werden die Themen Deployments, LogFiles durchgraben, Abstimmungen über falsche Versionen, Fallbackszenarien oder Releasenotes somit obsolet. Dies spart –  gut sie wissen es bereits – ebenfalls Zeit.

 

Enge Abstimmungen und Verschmelzungen der Tätigkeiten

DevOps_Abb2_740x415

Um das praktische Beispiel von oben abzuschließen. Es muss also der Betrieb von Anfang an mit im Boot sein, und nach dem DevOps Gedanken auch in permanenter Abstimmung mit der Entwicklung stehen. Es gibt eine, für das Unternehmen passende Toolchain z.B. im JAVA Umfeld IntelliJ (Entwicklungsumgebung) – Git (Codeversionierungen) – Maven – Jenkins (Buildserver) – Cucumber (Testing) – Puppet (Reporting, Kontrolle) oder im .NET Umfeld der TFS. Die Kombinationsmöglichkeiten heutzutage sind sehr groß und das Spektrum der verfügbaren Tools ebenfalls. Und wer sagt, dass die Tools nur die Entwickler oder der Betrieb verwenden sollen. Die Grenzen sind auch hier nicht mehr klar, oft programmieren sich Betriebsmitarbeiter Skripts, um automatisierte Routinen durchführen zu lassen oder testen selbst, um die fehlerfreien Betrieb der Software zu gewährleisten. Auch die Entwickler deployen selbst in Test- oder Integrationsstages. Also warum nicht eine Strategie entwickeln, wo die Tätigkeiten von allen durchgeführt werden können, um einen reibungslosen Ablauf zu gewährleisten?

 

Mindset schärfen: Zusammen bewegen wir mehr!

Was kann also noch schiefgehen? Leider sehr viel. Nicht nur das Beherrschen dieser Toolchain ist wichtig, sondern auch das gegenseitige Verständnis. Es ist eine zwischenmenschliche Sache, ein „über den Tellerrand blicken“. Es kann nicht mehr heißen: „Die Entwickler haben schon wieder ein fehlerhaftes Package geliefert“ oder „Die Vorlaufzeit im Betrieb ist ja ein Wahnsinn“. Vielmehr muss es ein Miteinander sein und nicht ein Schlagabtausch von Anschuldigungen, egal ob falsch oder auch berechtigt. Bei Letzterem muss man sich immer vor Augen halten, dass es immer einen Grund gibt, warum Menschen so reagieren wie sie reagieren. Es muss sich ein natürliches WIR etablieren, ein Team entstehen, das sich nicht mehr getrennt voneinander sieht. Kurz: ein DevOps-Team!

 

Conclusio: Dieser Weg wird kein leichter sein…

Wie kommen wir nun dahin? Die Antwort ist nicht pauschal zu beantworten. DevOps muss verstanden, etabliert und gelebt werden. Dafür ist, wie so oft, ein durchgängiges Commitment seitens des Managements notwendig, dass diese Änderung in der Unternehmenslandschaft auch getragen werden kann. Das Management muss dieses Mindset leben und aktiv begleiten. Dieser gesamte Vorgang ist ein Change, eine Veränderung, und Menschen reagieren auf Veränderungen per se sehr unterschiedlich. Deshalb müssen DevOps Schritt für Schritt entstehen. Ganz wichtig ist dabei, den beteiligten Mitarbeiten ein Ziel vor Augen zu halten, das verfolgt wird. Ihr Unternehmen wird davon profitieren. Bleiben Sie am Ball, bringen Sie die Leute zusammen, und besprechen Sie wie sie zu einer DevOps-Organisation werden können. Glauben Sie mir: der teils harte Weg wird sich lohnen und Ihre DevOps-Teams werden einen hohen Mehrwert für das ganze Unternehmen bringen.

Ich hoffe ich konnte ihnen einen kleinen Einblick in das Thema DevOps geben. Zunächst ist es ein Mindset, ein gemeinsames Tun und gegenseitiges Verständnis, unterstützt durch ein breites Portfolio an wirklich nützlichen Tools bzw. Toolchains. Finden Sie heraus was für Sie am besten funktioniert und definieren Sie Ihre DevOps so, wie sie es für richtig halten.

 

 

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*