Wir alle wissen, dass DevOps ein kultureller Wandel ist, der alle Ressourcen eines Unternehmens betrifft. Das Durchbrechen der so genannten „Wall of Confusion“, der Trennung zwischen Entwicklung (Dev) und Ops, bedeutet Zusammenarbeit, und DevOps fördert eine Kultur der Zusammenarbeit und des Lernens.
DevOps fördert funktionsübergreifende Teams und erfordert natürlich auch operative Spezialisten. Aber DevOps ist keine bestimmte Rolle oder ein bestimmtes Team.
Zum Thema „DevOps-Team“ gibt es selbst unter Experten widersprüchliche Meinungen: Sollte es ein DevOps-Team geben? Der Artikel „The Industry Just Can’t Decide about DevOps Teams“* zeigt verschiedene Standpunkte auf. Die am weitesten verbreitete Meinung ist, dass die Idee von DevOps-Teams kontraproduktiv ist: Es können zusätzliche Silos entstehen, und ganz allgemein sollten sich alle Ressourcen innerhalb einer Organisation der DevOps-Kultur anschließen.
Dies ist die Meinung von Theresa Naete in „Break down DevOps team roles so you can actually get to DevOps „**: „Der Punkt ist, dass wir nicht DevOps machen, wenn wir die Teams aufteilen.(…) In der DevOps-Welt gehören Dev und Ops zum selben Team. Ich wiederhole: Es ist das gleiche Team.
Was einige von uns nicht verstehen, ist, dass Kultur unverzichtbar ist und vor den Instrumenten kommt. Diese Kultur beinhaltet das Aufbrechen von Arbeitssilos und Barrieren und damit auch der Rollen innerhalb eines DevOps-Teams, damit jedes gewählte Tool optimiert werden kann, um die gewünschten Ergebnisse zu erzielen.“
Es gibt aber auch Befürworter der Idee, dass DevOps-Teams ein effektiver Weg sind, um den Übergang zu einer neuen Arbeitsweise zu vollziehen, und obwohl die Mehrheit der Branchenexperten der Meinung ist, dass Teams nicht der richtige Ansatz für die Entwicklung von DevOps-Fähigkeiten innerhalb einer Organisation sind, sind DevOps-Teams auf dem Vormarsch.
Das Ziel von DevOps in einem Unternehmen ist die Optimierung der Wertschöpfung für Kunden und das Unternehmen. Verschiedene Unternehmen benötigen möglicherweise unterschiedliche Teamstrukturen, um eine effektive Zusammenarbeit zwischen DEV und OPS zu erreichen. Das bedeutet, dass die ideale Struktur für die Umsetzung von DevOps von vielen Variablen abhängt.
DevOps-Rollen
Wie bereits erwähnt, gibt es keine universelle DevOps-Teamstruktur, die für alle passt (oder wir könnten sagen, dass es so etwas wie ein DevOps-Team gar nicht gibt!). Die Rollen und Zuständigkeiten sind je nach Unternehmen unterschiedlich: Wichtig ist, dass die wichtigsten Rollen und Zuständigkeiten ermittelt und den Mitarbeitern mit den richtigen Fähigkeiten zugewiesen werden.
Laut TechBeacon*** sind die häufigsten DevOps-Rollen, die für jedes Unternehmen, das den DevOps-Ansatz übernehmen möchte, entscheidend sind:
- DevOps-Evangelist: die Ressource, die die Vorteile von DevOps innerhalb des Unternehmens fördert. Er oder sie hat eine Leidenschaft für DevOps und sorgt für die Beteiligung und Unterstützung der Entwicklungs- und Betriebsteams. Der DevOps-Evangelist ist Ihr DevOps-Leader (Link zum Blogbeitrag DevOps Leader).
- Release Manager: manchmal auch Release Engineer oder Product Stability Manager genannt; verantwortlich für den Gesamtfortschritt, koordiniert und verwaltet das Produkt von der Entwicklung bis zur Produktion.
- Automatisierungs Architekt: auch Automatisierungsingenieur/Experte oder Integrationsspezialist genannt; analysiert, entwirft und implementiert verschiedene Strategien für die kontinuierliche Entwicklung des Produkts. Diese Funktion ist von entscheidender Bedeutung, da sie eine zuverlässige, vollautomatische und hindernisfreie Umgebung gewährleistet.
- Softwareentwickler/Tester: Diese Rolle ist natürlich das Herzstück einer DevOps-Organisation (sie ist die Dev von DevOps!). In einer DevOps-Umgebung sind die Entwickler jedoch nicht nur für die Umsetzung neuer Anforderungen in Code verantwortlich, sondern auch für Unit-Tests, Entwicklung und kontinuierliche Überwachung.
- Experience Assurance (XA) Professional: Während bei der „klassischen“ Softwareentwicklung die Qualitätssicherung (QA) eine wichtige Rolle bei der Lieferung des Endprodukts spielt, wird sie bei DevOps zur „Experience Assurance“, da diese Rolle auch sicherstellen muss, dass alle neuen Features und Funktionen unter Berücksichtigung der Erfahrung des Endbenutzers freigegeben werden.
- Security ingenieur: arbeitet mit den Entwicklern zusammen und sichert das zu entwickelnde Produkt.
Utility Technology Player: traditioneller IT-Betriebsexperte oder Systemadministrator, der sich auf den Betrieb von Servern konzentriert; arbeitet effektiv mit Entwicklungsplattformen, Netzwerken, Datenbanken, Servern und Tools.
DevOps-Kultur
DevOps einzuführen bedeutet, sich auszutauschen und zu lernen. Daher reicht es nicht aus, über die richtigen Ressourcen mit den richtigen Fähigkeiten zu verfügen, sondern das Team muss sich aus Ressourcen zusammensetzen, die bereit sind, kontinuierlich zu lernen und sich zu verändern.
Dies sind die drei Merkmale eines DevOps-Profis:
– weiß, wie man im Team arbeitet und passt gut in die Unternehmenskultur;
– ist ein neugieriger Mensch, der ständig experimentieren möchte und sich nicht scheut, zu versuchen und zu scheitern, bis er/sie verstanden – hat, was funktioniert und was nicht: DevOps ermutigt zum Scheitern, aber es muss ein „verantwortungsvolles Scheitern“ sein
ist eine anpassungsfähige Fachkraft, die Veränderungen positiv gegenübersteht.
Andere Quellen:
*Helen Beal, The Industry Just Can’t Decide about DevOps Teams
**Theresa Naete, Break down DevOps team roles so you can actually get to DevOps
***7 key DevOps roles you need to succeed- What Team Structure is Right for DevOps to Flourish?
