Wie Microsoft mit DevOps Software liefert

Microsoft verfügt über jahrzehntelange Erfahrung in der Bereitstellung hochskalierbarer Dienste für Produktionsumgebungen. Mit der Ausweitung der Microsoft-Dienste und -Umgebungen haben sich auch die Bereitstellungspraktiken im Laufe der Zeit weiterentwickelt. Viele Microsoft-Kunden haben diese effizienten Lieferverfahren ebenfalls übernommen und profitieren davon. Die folgenden Core DevOps-Prinzipien und -Prozesse können auf jede moderne Softwarebereitstellung angewendet werden.

Um DevOps-Bereitstellungsprozesse zu implementieren, hat Microsoft die folgenden Initiativen ergriffen:

• Ausrichtung der organisatorischen Denkweise und Kadenz auf die Lieferung.
• Bildung autonomer, rechenschaftspflichtiger Teams, die Funktionen besitzen, testen und bereitstellen.
• Shift right zum Testen und Überwachen von Systemen in der Produktion.

Fokus auf Lieferung

Ein schnellerer Versand ist ein offensichtlicher Vorteil, den Unternehmen und Teams leicht messen und schätzen können. Die typische DevOps-Kadenz umfasst kurze Sprint-Zyklen mit regelmäßigen Implementierungen in die Produktion.

Aus Angst vor mangelnder Produktstabilität bei kurzen Sprints hatten einige Teams dies mit Stabilisierungsphasen am Ende ihrer Sprint-Zyklen ausgeglichen. Die Ingenieure wollten während des Sprints so viele Funktionen wie möglich zur Verfügung stellen, sodass es während der Stabilisierung Testschulden zu begleichen galt. Teams, die ihre Schulden während des Sprints verwaltet haben, mussten dann die Teams unterstützen, die Schulden angehäuft haben. Die zusätzlichen Kosten schlagen sich in den Lieferpipelines und in der Produktion nieder.

Die Abschaffung des Stabilisierungszeitraums hat die Art und Weise, wie die Teams ihre Schulden verwalten, schnell verbessert. Anstatt wichtige Wartungsarbeiten auf die Stabilisierungsphase zu verschieben, mussten Teams, die Schulden angehäuft hatten, den nächsten Sprint damit verbringen, ihre Schuldenziele aufzuholen. Die Teams haben schnell gelernt, ihre Testschulden während der Sprints zu verwalten. Funktionen sind dann erfolgreich, wenn sie sich bewährt haben und die Kosten für die Bereitstellung wert sind.

Vollständige Automatisierung von Pipelines

Ein Großteil der Verbesserungen, die Teams sofort erzielen können, besteht darin, die Pipelines vom Code-Repository bis zur Produktion vollständig zu automatisieren. Zur Automatisierung gehören Release-Pipelines mit kontinuierlicher Integration (CI – continuous integration), automatisierten Tests und kontinuierlicher Bereitstellung (CD – continuous delivery).

Teams vermeiden vielleicht die Bereitstellung, weil es schwierig ist, aber je seltener sie bereitstellen, desto schwieriger ist es. Je mehr Zeit zwischen den Bereitstellungen vergeht, desto mehr Probleme häufen sich. Wenn der Code nicht frisch ist, gibt es Schulden bei der Bereitstellung.

Es ist einfacher, in kleineren Einheiten zu arbeiten, indem man sie häufig bereitstellt. Diese Idee mag im Nachhinein einleuchtend erscheinen, aber zu diesem Zeitpunkt erscheint sie oft kontraintuitiv. Häufige Bereitstellungen motivieren die Teams auch dazu, der Entwicklung effizienterer und zuverlässigerer Bereitstellungstools und Pipelines Priorität einzuräumen.

Verwendung interner Tools

Microsoft verwendet das von ihnen entwickelte Release Management System und liefert es an die Kunden aus. Eine einzige Investition verbessert sowohl die Produktivität des Teams als auch der Microsoft-Produkte. Die Verwendung eines sekundären Systems würde die Entwicklungs- und Liefergeschwindigkeit abschwächen.

Teamautonomie und Verantwortlichkeit

Es gibt keine spezifischen Fortschrittsindikatoren (Key Progress Indicators, KPIs), die die Produktivität oder Leistung des Teams messen oder zeigen, ob eine Funktion auf dem richtigen Weg ist. Die Teams müssen in der Lage sein, ihre eigenen Pläne und Rückstände zu verwalten und gleichzeitig einen Weg finden, sich an den Unternehmenszielen zu orientieren.

Es ist wichtig, direkt mit den Teams zu kommunizieren, um den Fortschritt zu verfolgen. Tools sollten die Kommunikation erleichtern, aber das Gespräch ist die transparenteste Art der Kommunikation.

Priorisierung der Funktionen

Ein wichtiges Ziel ist es, sich auf die Bereitstellung von Funktionen zu konzentrieren. Anhand von Zeitplänen lässt sich abschätzen, wie viel Teams und Einzelpersonen in einem bestimmten Zeitraum vernünftigerweise erledigen können, aber einige Funktionen werden früher und andere später geliefert. Teams können die Arbeit priorisieren, damit die wichtigsten Funktionen in die Produktion gelangen.

Die Verwendung von Microservices

Microservices bieten verschiedene technische Vorteile, die die Bereitstellung verbessern und vereinfachen können. Microservices bieten auch natürliche Grenzen für die Teamverantwortung. Wenn ein Team die Autonomie über die Investitionen in einen Microservice hat, kann es Prioritäten bei der Implementierung von Funktionen setzen und Schulden verwalten. Teams können sich auf Pläne für Faktoren wie die Versionierung konzentrieren, unabhängig von den Gesamtdiensten, die von dem Microservice abhängen.

Arbeit im Hauptzweig

Früher arbeiteten die Ingenieure in getrennten Abteilungen. Die Merge-Schulden auf jedem Zweig wuchsen, bis der Ingenieur versuchte, seinen Zweig in den Hauptzweig zu integrieren. Je mehr Teams und Ingenieure es gab, desto größer wurde die Integration.

Damit die Integration schneller, kontinuierlicher und in kleineren Stücken erfolgen kann, arbeiten die Ingenieure jetzt in der Hauptniederlassung. Ein wichtiger Grund für den Umstieg auf Git war das leichtgewichtige Verzweigungsprinzip, das Git bietet. Der Vorteil für die interne Entwicklung bestand darin, dass die tiefe Verzweigungshierarchie und ihre Auswirkungen beseitigt wurden. All die Zeit, die früher für die Integration aufgewendet wurde, wird jetzt in die Bereitstellung investiert.

Verwenden von Featureflags

Einige Funktionen sind für die Bereitstellung in einem Sprint noch nicht ganz fertig, können aber dennoch von Tests in der Produktion profitieren. Teams können diesen Code mit Funktionskennzeichen zusammenführen und bereitstellen, um die Funktion für bestimmte Benutzer zu aktivieren, z. B. für das Entwicklungsteam oder ein kleines Segment von Early Adopters. Feature-Flags kontrollieren die Exposition, ohne Probleme mit der gesamten Benutzerbasis zu riskieren, und können Teams dabei helfen, zu entscheiden, ob und wie das Feature fertiggestellt werden soll.

Testen in der Produktion

Shift Right to Test in Production hilft sicherzustellen, dass die Tests vor der Produktion gültig sind und dass die sich ständig ändernden Produktionsumgebungen für die Bereitstellung bereit sind.

Tests Instrumentierung und Metriken

Unabhängig davon, wo eine App bereitgestellt wird, ist es wichtig, alles zu instrumentieren. Die Instrumentierung hilft nicht nur bei der Identifizierung und Behebung von Problemen, sondern kann auch unschätzbare Erkenntnisse über die Nutzung des Systems und darüber liefern, was als nächstes hinzugefügt werden sollte.

Test des Resilienzmuster

Ein Risiko bei komplexen Bereitstellungen sind kaskadenartige Ausfälle, bei denen der Ausfall einer Komponente zum Ausfall abhängiger Komponenten führt und so weiter, bis das gesamte System zusammenbricht. Es ist wichtig, dass Sie wissen, wo einzelne Schwachstellen (Single Points of Failure, SPOFs) liegen und wie sie entschärft werden, und dass Sie die Entschärfungsprozesse testen, insbesondere in der Produktion.

Auswahl der richtigen Metriken

Die Entwicklung von Metriken kann problematisch sein. Ein häufiger Fehler ist es, zu viele Metriken einzubeziehen, um zu verhindern, dass Sie etwas übersehen. Dies kann jedoch dazu führen, dass Sie den Wert von Metriken, die nicht einem bestimmten Bedarf entsprechen, ignorieren oder ihnen misstrauen. Stattdessen nehmen sich die Microsoft-Teams Zeit, um die Daten zu ermitteln, die sie zur Erfolgsmessung benötigen. Teams können Metriken hinzufügen oder ändern, aber wenn Sie den Zweck von Anfang an verstehen, wird dieser Prozess erleichtert.

Neben der Grundlage einer Kennzahl überlegen die Teams auch, was sie mit der Metrik messen wollen. Zum Beispiel könnte die Geschwindigkeit oder Beschleunigung des Zuwachses an Benutzern eine nützlichere Metrik sein als die Gesamtzahl der Benutzer. Die Metriken variieren von Projekt zu Projekt, aber die hilfreichsten sind diejenigen, die das Potenzial haben, geschäftliche Entscheidungen zu beeinflussen.

Verwendung von Metriken zur Steuerung der Arbeit

Microsoft bezieht Metriken mit Überprüfungen auf den höchsten Führungsebenen ein. Alle sechs Wochen präsentieren die Unternehmen, wie es um ihre Gesundheit, ihr Geschäft, ihre Szenarien und ihre Kundentelemetrie bestellt ist. Die Unternehmen besprechen die Metriken mit den Führungskräften und ihren Teams.

Teams im gesamten Unternehmen untersuchen Metriken für engagierte Benutzer, um die Bedeutung ihrer Funktionen zu ermitteln. Teams liefern nicht einfach nur Funktionen aus, sondern achten darauf, ob und wie sie von den Benutzern genutzt werden. Die Teams verwenden diese Metriken, um die Backlogs anzupassen und festzustellen, ob Funktionen mehr Arbeit benötigen, um die Ziele zu erreichen.

Richtlinien für die Bereitstellung

• Der Weg von A nach B ist nie eine gerade Linie, und B ist auch nicht das Ende.
• Es wird immer Rückschläge und Fehler geben.
• Betrachten Sie Rückschläge als Lernchancen, um die Taktik für die Erledigung eines bestimmten Teils des Prozesses zu ändern.
• Im Laufe der Zeit entwickelt jedes Team seine DevOps-Praktiken weiter, indem es auf seinen Erfahrungen aufbaut und sie an die sich ändernden Anforderungen anpasst.
• Der Schlüssel liegt darin, sich darauf zu konzentrieren, einen Mehrwert zu liefern, sowohl für die Benutzer als auch für den Bereitstellungsprozess selbst.