Die DevOps-Philosophie leben

Teamarbeit in der agilen Entwicklung

| Autor / Redakteur: Christian Rentrop / Stephan Augsten

Gemäß der DevOps-Philosophie sollen Softwareentwicklung und Betrieb (Development und Operations) zu einem Unternehmensbereich konsolidiert werden.
Gemäß der DevOps-Philosophie sollen Softwareentwicklung und Betrieb (Development und Operations) zu einem Unternehmensbereich konsolidiert werden. (© Yabresse_Fotolia.com)

Mit DevOps lassen sich Prozesse der Softwareentwicklung effizienter gestalten. Update-Zyklen, die Geschwindigkeit der Entwicklung und die Software-Qualität sollen sich mithilfe des philosophischen Ansatzes verbessern. Die Implementation ist jedoch gegebenenfalls aufwändig.

Die allgegenwärtige Idee der Ganzheitlichkeit hat vor einiger Zeit auch die Softwareentwicklung erreicht: Die DevOps-Philosophie betrachtet Softwareentwicklung und Betrieb (Development und Operations, daher auch das Kofferwort DevOps) als laufendes System, in dem die verschiedenen Einzelteile möglichst reibungslos zusammenarbeiten sollen.

Die Praxis in IT-Unternehmen sah allerdings lange Zeit anders aus. Softwareentwicklung, der operative Bereich und nicht zuletzt der Kunde hatten verschiedene Vorstellungen von Update-Frequenzen, Software-Pflege und Qualität des Betriebs, was nicht selten massive Reibungsverluste nach sich zog.

Optimieren kann ein Unternehmen nur die internen gegenläufigen Vorstellungen, die wie folgt aussehen: Während die Entwickler vor allem Wert auf kreative Programmierung und flexible Anwendungen legen, setzt der Betrieb vor allem auf Sicherheit, Qualität und feste Zeitpläne. Es kann vorkommen, dass beide Abteilungen hier beinahe gegeneinander arbeiten, was mittelfristig natürlich auch den Kunden betreffen und gegebenenfalls dem Unternehmen schaden kann.

Mit DevOps effektiver arbeiten

Der DevOps-Ansatz verbindet die beiden Bereiche auch begrifflich. Das Kofferwort DevOps impliziert eine deutlich engere Zusammenarbeit der essenziellen Bereiche in Software-Unternehmen. So eng, dass der ganzheitliche Ansatz zum Tragen kommt; denn statt zweier Unternehmensbereiche soll es idealerweise nur noch einen geben, der sowohl die Entwicklung als auch den Betrieb der Software unterhält.

Die beschriebenen Reibungsverluste sollen damit vermieden werden. Sich widersprechende Abteilungen und das in IT-Unternehmen bei Fehlentwicklungen oder Kundenbeschwerden schlimmstenfalls auftretende Hin- und Herschieben des schwarzen Peters zwischen den beiden Bereichen lässt sich auf diese Weise effektiv vermeiden.

Stattdessen arbeiten beide Abteilungen Hand in Hand auf das gleiche Ziel zu – und sind damit auch deutlich besser greifbar. Vordenker des DevOps-Gedankens sind dabei derzeit vor allem Startups, bei denen er aus Personalmangel oder Geldnot mehr oder weniger automatisch realisiert werden muss.

Der Kunde ist König

In Unternehmen, die schnell und flexibel sein müssen und eine agile Softwareentwicklung nach dem Scrum-Prinzip anstreben – etwa Onlinedienste oder App-Anbieter – kann der operative Bereich sich nämlich als Bremse entpuppen. Gleichzeitig sind die kreativen und verspielten Entwickler aus Sicht derer, die den Betrieb und die Infrastruktur einer Software aufrechterhalten müssen, nicht selten ein Risiko für die Sicherheit oder den Betrieb an sich.

Gut erkennbar für Endnutzer ist die unterschiedliche Denke der beiden Bereiche zum Beispiel beim Vergleich zwischen kleinen Einzelentwicklern freier Software und den Betriebssystem-Riesen wie Apple oder Microsoft. Erstere pflegen Updates und Verbesserungen, Security-Updates, neue Features und andere Optimierungen nicht selten im laufenden Betrieb ein oder stellen sie über Nightly Builds zur Verfügung; Qualitätssicherung und Betriebsstabilität spielen hier nur eine untergeordnete Rolle.

Software-Riesen sind da in der Regel schon deutlich langsamer. Sie liefern in großen Abständen große Update-Pakete in Form von Service-Packs – hier hat der operative Bereich das Sagen, was im Hinblick auf Sicherheit und Qualität bei einer derart großen Software-Basis natürlich mitunter die sinnvollere Option sein kann.

Zwischen diesen Extremen steht jedoch der Kunde. Dieser will einerseits jederzeit „up to date“ sein, legt aber andererseits vor allem im professionellen Bereich enormen Wert auf Sicherheit und Stabilität. Inzwischen hat sich der Kundenwunsch allerdings in vielerlei Hinsicht geändert: Waren früher jährliche Major-Releases ausreichend, sind heute immer wieder kleine Verbesserungen und Optimierungen zu lesiten, nicht selten sogar auf direkten Kundenwunsch. Einige große Unternehmen wie Amazon und nicht zuletzt Facebook verfolgen diesen Ansatz bereits, zumindest bei der Frontend-Entwicklung.

Mit DevOps werden Entwickler verantwortlich

Der DevOps-Ansatz versucht daher, die Entwickler auch in den operativen Bereich der Software einzubinden. Alles muss im Hinblick auf Sicherheit und Qualität entworfen, entwickelt und programmiert werden. Gleichzeitig muss eine Code-Ownership-Policy entworfen werden, die den Entwickler für „seinen“ Code verantwortlich macht.

Das soll unter anderem dafür sorgen, dass Missverständnisse und Fehler vermieden werden. Gleichzeitig soll die Code-Qualität verbessert werden: Ein einzelner Entwickler kann Fehler und Bugs nicht mehr auf sein Team abwälzen, während er solche Fehler gleichzeitig natürlich schneller beheben kann als ein Dritter.

Einen Ansatz, der sogar ohne Vorab-Tests auskommt, fährt beispielsweise Facebook. Die kontinuierliche Softwareentwicklung sorgt dafür, dass immer nur wenig zum großen Ganzen geändert wird. Dabei wird neuer Code zum Beispiel auch nicht sofort für alle Facebook-Nutzer ausgerollt. Ein „Gatekeeper“ genanntes System sorgt dafür, dass neue Funktionen zunächst nur einem Bruchteil der User zur Verfügung gestellt wird.

Aufwändige Beta-Tests kann sich Facebook auf diese Weise sparen. Der Code wird direkt an einem Teil der User getestet und von Ingenieuren überwacht. Kommt es zu Problemen, ist schnell nachvollziehbar, wer hier für das Bugfixing zuständig ist. Läuft der Test hingegen erfolgreich, wird das Feature oder der Fix an alle User ausgerollt.

Konzept nicht zwingend übertragbar

Natürlich ist das Facebook-Modell nicht auf jedes Software-Unternehmen übertragbar. Gerade dort, wo sicherheitsrelevante oder für die Aufrechterhaltung des Betriebs zwingend notwendige Funktionen überarbeitet werden, müssen die Kontrollinstanzen nach wie vor eng gesetzt werden. Praktisch kann die DevOps-Idee jedoch auch in größeren Unternehmen oder Softwareschmieden mit erhöhtem Anspruch an Sicherheit und Stabilität sein – allein, weil die Wege kürzer und die Verantwortlichkeiten klarer gesetzt werden.

Für IT-Verantwortliche können DevOps ein Weg sein, den gesamten Prozess von der Planung bis zum Release deutlich schneller und zuverlässiger durchzuführen. Allerdings sind vorab einige Fragen zu klären. Zunächst muss klar sein, dass der Kunde im Fokus stehen muss; es geht um echte Menschen und damit auch um echtes Geld, das durch eine halbgare Implementierung der DevOps möglicherweise vor Probleme gestellt werden, die andernfalls nicht passiert wären.

Von daher muss, das ist der zweite wichtige Faktor, die konkrete Umsetzung des DevOps-Konzepts auch zum Unternehmen und dem Produkt passen. Die Möglichkeiten sind hier vielfältig, am Anfang müssen jedoch immer Management-Prozesse stehen, die die Möglichkeiten und Chancen betriebsintern erforschen und ein sinnvolles Konzept entwickeln.

Zu guter Letzt ist die DevOps-Philosophie natürlich auch eine Kostenfrage. Das Investment wird sich zwar langfristig auszahlen, bis dahin verursacht die Umstrukturierung aber natürlich Aufwand in Form von Kosten, Personalwechseln und natürlich der Vorarbeit des DevOps-Konzepts – vor allem in bereits bestehenden Systemen.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44432539 / Continuous Delivery & Integration)