Im Atlassian Developers-Blog hat Ian Buchanan einen interessanten Artikel zum Thema DevOps veröffentlicht. Wie bereits im vorangegangen Teil begonnen, untersucht die Artikelreihe die Möglichkeit, das Agile Fluency-Model mit DevOps zu vereinen.

Das Agile Fluency-Modell hilft dabei, die Lücke zwischen Erwartung und Realität zu verstehen, und postuliert, dass sich die Einführung von agilem Vorgehen in klar getrennte Schritte mit jeweils unterschiedlichen Investments und Vorteilen unterteilen lässt. Buchanan schlägt vor, die Ideen von Agile Fluency auf Konzepte aus dem Bereich DevOps abzubilden. Dazu überträgt er die vier Phasen aus der agilen Welt auf die Thematik von DevOps.

Im letzten Teil haben wir die erste Phase – wie sich Teams auf Unternehmenswerte ausrichten können – betrachtet. Im vorliegenden Artikel werden wir die zweite Phase untersuchen, die sich um Wissensbildung und Schaffung von Werten dreht.

Ein gemeinsames, technisches Verständnis als Grundlage

Die zweite Phase (Delivering Value) schließt die Lücke zwischen Inselwissen von Einzelpersonen und gemeinsamem Lernen von Teams. Ein Beispiel für eine solche Lücke ist die Diskrepanz in der Frage, wie man denn eigentlich „Continuous Integration macht“. Zwar haben mitunter alle Mitglieder eines neu gebildeten Teams die fachliche Kompetenz und ausreichend Erfahrung – aber verstehen unter diesem Begriff höchst unterschiedliche Werkzeuge und Vorgehensweisen. Dieses Wissen gilt es zu synchronisieren.

Die erste Phase hatte eine Veränderung der Team-Kultur zur Aufgabe. Die zweite Phase ist eine Investition in das Team, gemeinsam technische Praktiken zu erlernen und vorhandenes Wissen auszutauschen. Vielleicht benötigt man dazu einen weiteren agilen Coach mit mehr technischem Know-How. Oder vielleicht benötigt man parallel zum Product Owner einen „Technical Owner“, welcher technische Entscheidungen treffen und Automatisierungen priorisieren kann.

Technische Spielereien vermeiden und neue Werte schaffen lernen

Buchanan selbst beschreibt eine Situation mit monatelanger verringerter Produktivität, bis sich eine entsprechende agile Leichtigkeit (Fluency) eingestellt hatte, obwohl das Team aus erfahrenen agilen Entwicklern bestand. Unter Umständen kann der Prozess Jahre dauern, falls das Team noch nicht firm in agilen Vorgehensweisen ist. Der Ratschlag an dieser Stelle lautet: Neue Dinge ausprobieren birgt Risiken – vermeiden Sie es, die Dinge schlimmer zu machen, weil Sie zu viele neue Technikspielereien gleichzeitig starten.

Diese zweite Phase birgt aber noch weitere Vorteile. Automatisierung bedeutet auch gleichzeitig, Werte zu schaffen. Viele agile Teams sind bereits in der Lage, sich mit zweiwöchigen Sprints und „potentially shippable Code“ auf das Erfassen von Werten auszurichten. Diese hohe Frequenz führt dazu, dass mögliche Hindernisse frühzeitig aufgedeckt werden können. Werte zu schaffen bedeutet aber mehr als lediglich regelmäßige Termine zu haben. Werte zu schaffen bedeutet, der Organisation die Kontrolle über die Auslieferung zu geben. Somit kann das Unternehmen sich darauf einstellen, in welcher Häufigkeit der Markt neue Veröffentlichungen von Software verlangt – und darauf entsprechend reagieren. An diesem Punkt wird ein Team aufgrund von hoher Produktivität und niedrigen Fehlerraten vom Management positiv wahrgenommen werden.

Extreme Programming als Rahmen nutzen

Eine lange bewährte Vorgehensweise mit einem ganzen Koffer voller agilen Praktiken für diese Phase ist Extreme Programming. So können beispielsweise Techniken wie Programmierkonventionen (Coding Standards), Unit Tests auf Basis von Test-Driven Development, automatisierte Akzeptanztests, Pair Programming oder aber auch Continuous Integration, gemeinsamer Code-Besitz (Collective Ownership) und Refactoring massive Erleichterungen bringen. Es ist nicht einfach, in dieser Phase Werkzeuge und Praktiken getrennt zu handhaben. Bis auf Pair Programming und gemeinsamen Code-Besitz stellen Automatisierungswerkzeuge quasi Abbildungen der entsprechenden XP-Praktiken dar. So kann Bamboo zur Umsetzung von Continuous Integration dienen.

xp_uebersicht

Mit Software zur Automatisierung – und noch weiter

Mit Hilfe von statischen Codeanalyse-Werkzeugen (wie FindBugs, Checkstyle oder PMD) und IDEs lassen sich Programmierkonventionen durchsetzen. Mit sprachgebundenen Frameworks wie JUnit lassen sich entsprechend Unit- und Akzeptanztests umsetzen. Mit Bamboo lässt sich das Prinzip von Continuous Integration realisieren, um alle diese Aufgaben automatisch durchzuführen – bei jedem neuen Commit in das Versionskontrollsystem.

Vernünftige Werkzeuge machen agile Praktiken greifbarer und einfacher umzusetzen, was wiederum die unternehmensinternen Abläufe sichtbarer macht und näher an den Geschäftswerten ausrichtet. An diesem Punkt kapselt sich die Softwareentwicklung ab, und es werden repetitive Vorgänge automatisiert. Diese Art der Automatisierung macht DevOps für Entwickler so attraktiv.

Für manche Teams mögen die Praktiken aus dem Bereich von Extreme Programming ausreichend sein, um Werte zu schöpfen. Für Open Source-Projekte oder Software auf CD mag „Done“ bedeuten, dass die letzte Version gepackt und getestet wurde. Für manche Projekte gilt aber, dass die Software erst von Wert ist, sobald sie ausgeliefert wurde. Es ist also ratsam, sich in der agilen Softwareentwicklung auch über den IT-Betrieb Gedanken zu machen – so wie es Scott Ambler bereits mit den Production- und Retirement-Phasen im Enterprise Unified Process getan hat. Jedoch scheint es so, dass erst mit DevOps Bewusstsein für die Bedeutung des IT Betriebs in der Wertschöpfungskette geschaffen wurde. Jez Humble und David Farley sind die Verfechter einer holistischen Sicht auf die Schaffung von Werten, welches als Continuous Delivery der breiten Öffentlichkeit bekannt gemacht wurde. Im gleichnamigen Buch erweitern die Autoren automatisches Testen und kontinuierliche Integration zu einer potenziell vollautomatischen Deployment Pipeline.

5 - CI in Deployment Pipeline

Mit Atlassian Bamboo als Continuous Delivery-Lösung zum DevOps-Erfolg

Innerhalb des Atlassian-Toolsets wird diese Funktionalität durch Bamboo in Form von Deployment Projects bereitgestellt.

Deployment-Projekte modellieren eine Deployment-Pipeline in Form von Umgebungen wie zum Beispiel Entwicklung, QA, Staging oder Produktion. Bamboo verfolgt und historisiert die Veröffentlichung einer Anwendung in eine solche Umgebung. Zwar sind die Bausteine für die Automatisierung dieselben wie bei Continuous Integration, aber um eine Pipeline umfassend nachverfolgen zu können, werden zusätzliche Informationen benötigt. Bamboo ist in der Lage, diese Daten für unterschiedliche Zielgruppen aufzubereiten, sodass sich neben Entwicklern auch Tester oder der IT Betrieb im Werkzeug heimisch fühlen.

2-Systematisches Continuous Delivery

Wie DevOps mit Atlassian-Werkzeugen bei Ihnen aussehen kann, zeigt die Braintime-Lösung zu Continuous Delivery mit Atlassian-Werkzeugen. Weitere Informationen bieten die passenden Talks in unserem Vortragsarchiv. Zögern Sie nicht, uns bei weiteren Fragen zu kontaktieren.

Ausblick: Messen und Optimieren auf Unternehmensebene

Im weiteren Verlauf dieser Artikelreihe widmen wir uns den Problemen, denen sich ein DevOps-Team auf der Reise zur Eigenständigkeit stellen muss.

So betrachten wir als nächstes die Frage, wie man Unternehmenswerte überhaupt messen kann, bevor wir uns mit der Thematik der Gesamtoptimierung auf Unternehmensebene befassen.