,

Sieben bewährte DevOps Praktiken in Microsofts DevDiv

Sieben bewährte DevOps Praktiken in Microsofts DevDiv

Daniel Meixner – Technologieberater für Applikationsentwicklung bei Microsoft – erklärt, was DevOps für seine Arbeit bedeutet und die sieben Prinzipien, nach denen sich sein Team organisiert.

Dieser Beitrag stellt sieben Praktiken vor, die Microsofts DevDiv – die Entwicklungsmannschaft von Microsoft, die Softwarewerkzeuge für Entwickler entwickelt – nutzt, um Visual Studio Team Services (VSTS) – eine cloudbasierte Plattform für Softwareprojekte – zu entwickeln. Dabei sei bereits an dieser Stelle erwähnt, dass diese eben für uns funktionieren und bedeutend sind. Das heißt nicht, dass diese verpflichtend zu implementieren sind oder generell erfolgversprechend wären. Allgemein ist festzuhalten, dass bei der konkreten Umsetzung immer auf individuelle Umstände eingegangen werden muss. Allerdings ist es absolut empfehlenswert, einfach mal zu sehen wie andere Unternehmen mit bestimmten Herausforderungen umgehen. In diesem Sinne sind die folgenden Punkte keinesfalls als Vorschrift, sondern vielmehr als Inspiration und Impuls zu sehen.

Das Ziel von DevOps

Bevor es an die sieben Punkte geht, noch eine kurze Einführung: Was ist DevOps? 

Statt eine umfassende Antwort auf diese Frage zu geben, bevorzuge ich es, das Ziel von DevOps zu beschreiben. Das geht am einfachsten mit drei Worten, die im Englischen geschmeidiger klingen als im Deutschen: Continuous Value Delivery. Ich mag diese Formulierung, weil jedes einzelne Wort davon wichtig ist:

Delivery – Weil man bei DevOps danach strebt, die Software nicht nur zu bauen, sondern auch an den Endandwender auszuliefern.
Nur was beim Endanwender ist, hilft. Kompilierte Software im „Regal“ bringt niemanden weiter.

Value – Weil es darum geht, etwas zu liefern, was dem Kunden etwas nutzt.
Das bringt Fokussierung auf die wirklich wichtigen Dinge und sorgt gleichzeitig dafür, dass auch Themen eingeschlossen sind, die nicht unbedingt durch die Entwicklungsabteilung geleistet werden müssen. In diesem Sinne stellt zum Beispiel das Aufstocken eines Clusters von 20 auf 50 Maschinen einen Wert für den Endanwender dar, wenn sich dadurch die Performance verbessert. Klassischerweise würde man das aber vielleicht als eine Aufgabe der Betriebsabteilung oder der Admins sehen – die Entwicklungsabteilung bekommt davon vielleicht gar nichts mit. Hier wird deutlich, dass beide Parteien – Ops-Teams & Dev-Teams – als „wertschöpfend“ anerkannt werden – und nicht als Kostenfaktor gelten.

Continuous – Weil es heute nicht mehr reicht, nur alle Schaltjahre ein Release zu veröffentlichen. Sicherlich kann man darüber diskutieren, wann genau man jetzt eigentlich „kontinuierlich“ liefert –  mehrfach am Tag oder alle paar Wochen? Natürlich spielen individuelle Faktoren eine Rolle: Den Algorithmus eines Webservice, der nur über eine API erreichbar ist, kann man vielleicht leichter und reibungsloser updaten als die Oberfläche einer Website, die der Anwender sieht. Komplizierter ist es, wenn es um Software geht, die beim Kunden installiert ist – bspw. auf dem Smartphone. Hier geht es irgendwann nicht mehr nur um die Frage des technisch machbaren, sondern auch darum, was zumutbar ist. Der berechtigte Anspruch von Endanwendern auf Aktualität sowie die Schnelligkeit, mit der sich die Technologie weiterentwickelt und Märkte sich wandeln, fordern zusätzlich eine Beschleunigung bestehender Prozesse ein.

Aus dem Nähkästchen geplaudert

Mit diesem Ziel vor Augen kann man sich auf die Reise ins DevOps-Land begeben. Gene Kim beschreibt in seinem Buch The Phoenix Project sehr anschaulich die „3 ways of DevOps“, die allerdings noch sehr abstrakt gehalten sind. (Das Buch ist dennoch in jedem Fall sehr lesenswert.) Die konkrete Implementierung in Microsofts DevDiv stützt sich auf die folgenden sieben Praktiken, die letztlich auch Kims „3 ways“ wiederspiegeln.

1. Fokussierung auf den Fluss von Werten

Eingehend mit dem beschriebenen Ziel und auch mit dem ersten der „3 Ways“ von Gene Kim ist ein hoher Grad an Automatisierung unabdingbar, um den Fluss eines Wertes zum Kunden zu beschleunigen. Konkret bedeutet das bspw. die Implementierung von automatischen Tests, einer Continuous Integration und Continuous Deployment Pipeline und ein leistungsfähiges Release Management. Als Beispiel aus der Praxis: Ein Git Pull-Request (PR) im Entwicklerteam von Visual Studio Team Services stößt automatisch einen PR-Build an, in dessen Zuge aktuell rund 68.000 automatisierte Tests abgearbeitet werden. Damit der Entwickler nicht allzu lange warten muss, bis er weiß, ob seine Codeänderung brauchbar ist, wurde das Ziel ausgerufen, diese Tests innerhalb von weniger als 10 Minuten durchzuführen – was letztlich natürlich auch den Wertefluss beschleunigt, da die Feedbackschleife für den Entwickler kurz gehalten wird. Gleichzeitig werden zur kompletten Orchestrierung und Automatisierung von Builds, Tests und Releases von neuen Versionen von Visual Studio Team Services die Features von Visual Studio Team Services selbst verwendet – schließlich ist Team Services ja unsere Plattform für viele Belange rund um DevOps. Diese Verwendung von eigenen Produkten firmiert unter dem Namen „Dogfooding“ oder „Eat your own dogfood“: Um uns zu vergewissern, dass wir wirklich wertschöpfende Funktionen liefern, nutzen wir unsere eigene Software so, wie wir es dem Endkunden empfehlen würden.

Eat your own dogfood, Automatisierung, Release Management
Team Services im Einsatz bei der Entwicklung von Team Services: Mehr als 68000 Unittests wurden in weniger als acht Minuten durchgeführt – ausgelöst durch einen Pull Request. Einer schlug fehl. Schade.

2. Autonomie vs. Anpassung

In großen Entwicklungsteams benötigt man Abstimmung und eine gemeinsame Ausrichtung – anderenfalls weiß die linke Hand nicht, was die rechte tut. Gleichzeitig ist es wichtig, Freiheiten zu schaffen, wo diese Abstimmung und konkrete Vorgaben nicht notwendig sind. Mit Sicherheit ist es im Einzelfall abzuwägen, wie das genau aussehen muss. Aber dieser Aufwand ist lohnenswert: Wenn man es hier schafft, maßvoll zu agieren, wird Frustration, die durch Überregulierung entsteht, verhindert und Motivation und Kreativität gefördert.
Beispielsweise sind intern im Sinne der Abstimmung Begriffe wie „Scenario“ konkret definiert worden – man ist sich teamübergreifend darüber klar, was der Planungshorizont für ein Scenario ist, die „Taktung“ der Iterationen ist teamübergreifend festgelegt, ebenso wie die Benennung der Durchläufe: Aktuell befinden sich alle Teams der Team Services Entwicklung im Sprint 129. So wird die Kommunikation leichter und jeder weiß immer, wo man sich auf der Zeitachse befindet.

Innerhalb der Abteilung hat man sich auch darauf geeinigt, dass es ein zentrales Tool gibt, in dem der Projektfortschritt dokumentiert wird – wenig überraschend ist es, dass es sich dabei um Visual Studio Team Services selbst handelt. Auf dieser Ebene ist Alignment natürlich auch absolut sinnvoll, da man sich so schnell Überblick verschaffen kann, wo das Gesamtprodukt steht.

Hingegen ist es vielleicht durchaus überraschend, dass ein einzelnes Entwicklungsteam die tägliche Arbeit – also jeden einzelnen Entwicklungstask – nicht zwingend in VSTS hinterlegen muss: So gibt es bspw. Teams, die für das Tracking kleinerer Tasks lieber OneNote verwenden.

Warum ist das so? Die Erklärung ist einfach: Man will nur da Vorgaben machen, wo sie zwingend notwendig sind – alles andere würde für unnötige Reibung sorgen und letztlich von der eigentlichen Tätigkeit abhalten. Konkret ist für den Gesamtprojektfortschritt in diesem riesigen Projekt mit knapp 500 Entwicklern ein einzelner Entwicklertask mit einem Zeitaufwand im Stundenbereich zwar sicher ungeheuer wichtig – aber in der Regel nicht maßgebend, um den Fortschritt des Gesamtprojekts zu reflektieren. Demzufolge ist das Reporting in ein zentrales Tool in diesem konkreten Fall nicht bedeutend, solange das einzelne Entwicklerteam und die direkten Kollegen den Status der Tätigkeit wissen. Hier entscheidet also jedes einzelne Team. Wichtig ist allerdings, dass für die größeren Teilaufgaben – zum Beispiel die Pakete, in denen auch teamübergreifen Abstimmung notwendig ist – Transparenz herrscht. Daher sind diese wiederum im Tool hinterlegt.

Ich halte das für nachvollziehbar, auch aus eigener Erfahrung: Allzu oft geschieht es, dass bestimmte Vorgehensweisen und Tools im Sinne von eigentlich erstrebenswerter Vereinheitlichung und Erleichterung „übergestülpt“ werden – und dadurch unnötig Reibung entsteht sowie funktionierende Workflows gebrochen werden. Es kommt aber wie so oft auf die Perspektive an – und genau das ist der Knackpunkt: Wann brauche ich Abstimmung und eine „Ansage von oben“ wie zu arbeiten ist? Was gewinne ich dadurch? Und wann kann ich Autonomie gewähren? Die Beantwortung dieser Fragen ist aber sicher immer individuell.

3. Optimierung des Backlogs durch neue Erkenntnisse

Das „Backlog“ beinhaltet die geplanten Features. Wer entscheidet eigentlich, was im Backlog steht? Klassischerweise kann das die Aufgabe eines Program Managers (PM) sein. Aber woher nimmt diese Person all die notwendige Weisheit? Wieso sollte ein PM es besser wissen als irgendjemand sonst? Die Realität zeigt, dass auch ein PM mal danebenliegt. Damit daraus kein größeres Problem wird, ist es notwendig, eine Kultur zu schaffen, in der man auch einmal danebenliegen darf – das heißt, man ist bestrebt die interne Wahrnehmung einer Fehlentscheidung (bspw. für ein Feature, das niemand benutzt) zu ändern. Eine Fehlinvestition ist eben nicht nur der Verlust von Ressourcen, sondern auch eine neu gewonnene Erkenntnis. Letztlich hat man eben mit jedem Fehler auch etwas dazu gelernt. Diese Auffassung erlaubt das inkrementelle Anpassen von Ideen und ermöglicht es auch einmal daneben zu liegen, indem sie dies kulturell erlaubt.

4. Beweise aus dem Produktivbetrieb

Der einzige echte Beweis, ob ein Feature einen Wert darstellt, findet sich darin, ob und wie ein Feature verwendet wird. Um das herauszufinden, hilft Telemetrie. Man macht also messbar, was bisher auf Vermutungen angewiesen war. Dies hilft bei Neuentwicklungen, um Aussagen über bevorzugte Workflows machen zu können und bei alternativen Entwicklungen, um die beste Variante herauszufinden. Konkret bedeutet das: Es kann hilfreich sein, bestimmten Nutzergruppen (beispielsweise Early Adopters) eine alternative Oberfläche zu bieten und dann die Telemetriedaten aus diesem Nutzerkreis mit der normalen Variante zu vergleichen. Gegebenenfalls können über Abweichungen hier Aussagen getroffen werden, was die bessere Lösung ist. Wichtig ist allerdings: Eine solche Aussage ist keineswegs immer trivial – gegebenenfalls spielen viel mehr Faktoren eine Rolle: Ist die neue Variante wirklich besser oder sind die Early Adopters vielleicht ohnehin die Nutzergruppe, die im Umgang mit der Software routiniert ist?

5. Management von Technische Schulden

Technische Schulden entstehen, wenn man anfängt, Dinge auf später zu verschieben, die eigentlich gleich erledigt werden müssten. Es ist die leichteste Art einen Bug loszuwerden, indem man sagt „Das machen wir in der nächsten Version!“. Schwuppdiwupp ist der Schreibtisch wieder frei für Dinge, die mehr Spaß machen. Leider führt das mittelfristig dazu, dass man einen ganzen Berg von Problemen ansammelt – den man irgendwann angehen muss. So macht man über einen langen Zeitraum gar keine Fortschritte und für Kunden ist keine Innovation mehr ersichtlich, weil man eigentlich nur Fehler behebt und keine neuen Features implementiert.

Es hat sich bewährt, Wert darauf zu legen, dass einzelne Teams nicht zu viele Bugs ansammeln. Durch das Tracking der Bugs im zentralen System ist die „Buglast“ der Teams transparent sichtbar und notfalls wird eben in einem Sprint nur in Bugfixing investiert statt in neue Features. Wichtig ist die Intention, die Werkbank von Beginn an sauber zu halten und technische Schulden gar nicht erst aufkommen zu lassen.

In diese Kerbe schlägt natürlich auch die Strategie, Probleme generell frühzeitig zu erkennen – am besten automatisiert über Tests oder sogar noch früher im Rahmen von Code Reviews. Insgesamt gilt: Je „weiter links“ auf der Zeitachse ein Problem erkannt wird, umso besser. Diese Strategie ist auch als „Shift Left“- Ansatz bekannt.

6. Production First!

Wenn das Ziel von DevOps „Delivery“ ist, dann ist die Umgebung, in der die Kunden arbeiten die wichtigste. Das erfordert, alles zu tun, damit hier keine Fehler auftreten – und wenn doch, müssen wir alles daran setzen, diese schleunigst zu beheben. Dazu bedarf es eines umfassenden Monitorings, das den aktuellen Zustand der Gesamtapplikation und der Infrastruktur wiedergibt. Im Zuge von Continuous Deployment werden automatisch die Updates eingespielt – ohne manuelle Interaktion jenseits der Freigaben. Einzelne Features werden frühzeitig in den Masterbranch integriert und auch möglichst schnell ausgeliefert, teilweise ohne für den Anwender sichtbar zu sein, weil sie vielleicht noch gar nicht fertig sind. Dies stellt sicher, dass die Integration ins Gesamtsystem funktioniert und ausgiebig getestet ist, lange bevor ein Feature für den Anwender „sichtbar“ wird. Konkret arbeiten wir an dieser Stelle mit Feature Flags um bestimmte Features so lange zu verbergen, bis sie wirklich „reif“ sind. Die Integration und das Ausliefern der meisten Komponenten hat dann aber längst schon stattgefunden, wodurch die Stabilität im Betrieb gewährleistet wird.

Und wenn doch etwas schief geht? Dann belegen die Blogposts von Brian Harry eindringlich, wie intern vorgegangen wurde, um das Problem zu entdecken, zu beheben und wie die Kette der Abläufe war – eindrucksvoll nachzulesen beispielsweise hier und hier. Natürlich hilft das betroffenen Kunden erstmal nicht direkt weiter, aber die Transparenz über unsere internen Vorgehensweise sorgt intern natürlich auch für eine gewisse Verpflichtung gegenüber unserer Kunden.

7. Infrastruktur ist flexibel

Es hilft, sich nicht mehr viel Gedanken um Infrastruktur machen zu müssen. Wenn ein einzelner Service mehr Kapazität benötigt, dann kann man diesen dynamisch hinzuschalten. Wenn eine Testumgebung benötigt wird, dann wird sie hochgefahren. Wenn man Tests parallel ausführen möchte, um Zeit zu sparen, dann hat man gefühlt unbegrenzt Infrastruktur zur Verfügung, um diese zu nutzen. Diese Flexibilität erlaubt es, die Geschwindigkeit, die man über den Entwicklungsprozess und über agile Vorgehensweise gewonnen hat, jetzt auch auf die Straße zu bringen. Wenn Kapazitäten gefragt werden, dann sind sie da – ohne die Kapazitäten ständig selbst vorhalten zu müssen.

Das VSTS Team entwickelt VSTS mithilfe von VSTS – und VSTS läuft in der Cloud, die genau diese Flexibilität in Hinblick auf Buildagents, Testumgebungen und jeglichen erforderlichen Infrastrukturkomponenten für den Betrieb der Software zur Verfügung stellt – und mit zunehmendem Nutzen einfach mitwächst.

 

Wie bereits beschrieben, sollen diese Punkte inspirieren, wenn es darum geht, den eigenen Weg in Richtung DevOps einzuschlagen. Mehr zur Arbeitsweise der DevDiv findet sich in Form von zahlreichen Videos und eines Whitepaper. Das beschriebene Produkt Visual Studio Team Services ist eine plattformunabhängige Umgebung, um DevOps Prozesse abzubilden – inklusive cloudbasierten Buildservern auf Linux, MacOS und Windows. Wer diese Plattform ausprobieren möchte, kann dies hier tun.


Über den Autor des Beitrags:

Daniel Meixner

 

Daniel Meixner ist Technologieberater zu Applikationsentwicklung bei Microsoft und beschäftigt sich mit DevOps Best Practices und der Entwicklung auf Basis von Microsoft Azure. Er ist bekennender Fanboy der Visual Studio Produktfamilie und hat in seiner langjährigen Erfahrung in unterschiedlichen Rollen - vom Anwendungsentwickler bis zum Evangelisten - das „Gute, Schlechte und Hässliche“ in der Softwareentwicklung zu genüge und aus unterschiedlichsten Blickwinkeln kennengelernt. Dieses Wissen bringt er mit, wenn es darum geht, Lösungen zu diskutieren und zu implementieren, die typische Herausforderungen in der Software-Entwicklung adressieren.

Daniel Meixner bloggt unter www.DevelopersDevelopersDevelopersDevelopers.NET und ist auf Twitter als @DanielMeixner unterwegs.

Leave a reply

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