TECH BLOG - Einleitung 2. Teil: CI/CD Patterns and Best Practices

Nachdem wir uns im vorherigen Blog-Beitrag mit Anti-Patterns beschäftigt haben, konzentrieren wir uns hier nun auf die richtige Vorgehensweise. Es gibt viele Best Practices wenn es um CI/CD geht - ich habe versucht, Patterns auszuwählen, die entweder sehr wichtig sind oder oft falsch gemacht werden. Letzteres ist der Fall für unser erstes Thema.

Continuous Integration ist kein Tool

Ich habe dieses Zitat irgendwo im Internet gefunden denke, es passt sehr gut:

Zuerst die schlechten Nachrichten:

• Jenkins ist nicht CI.
• JUnit ist nicht unit testing.
• Jira ist kein User Story Management.

In diesem Sinne ist Continuous Integration eine Methode, kein Tool. Es gibt einen wirklich guten Blogbeitrag dazu aus 2005, der immer noch relevant ist und die Botschaft perfekt unterstreicht: http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html.

Wenn Sie CI richtig machen wollen, müssen die Entwickler verstehen, dass es bei CI darum geht, Code regelmäßig zu integrieren und zu testen. Es gibt einige Best Practices, die beim Start helfen können:

• Bis auf wenige Ausnahmen sollten alle Entwickler direkt am Master-Branche arbeiten. Auf diese Weise führt jeder Check-in zu einer sofortigen Integration und Testing. Früher haben Entwickler an Feature-Branches gearbeitet - aber dann erfolgt die Integration nicht mehr direkt beim Einchecken, sondern erst beim Zusammenführen der Änderungen mit dem Master. Feature-Zweige können natürlich verwendet werden, aber dann sollten sie täglich mit dem Master zusammengeführt werden. Hier ist ein guter Beitrag zu Branches und CI: https://martinfowler.com/bliki/FeatureBranch.html

• Es sollte einen klaren und einfachen CI-Prozess für die Entwickler geben: Der Prozess beschreibt die Schritte, die ausgeführt werden müssen, wenn Code an den Master übergeben wird. Zum Beispiel sollten Sie zuerst ein Update machen und prüfen, ob ein Build bereits läuft. Nach dem Check-in sollten Sie den Build und den ersten Einsatz beobachten und darauf achten, dass Sie nichts zerstört haben. Ein 7-Schritte-Prozess wird im Buch über Continuous Delivery beschrieben: https://martinfowler.com/books/continuousDelivery...

• Achten Sie darauf, dass Build und Deployments nicht zu lange dauern - das ist ein Show-Stopper für CI, denn wenn etwas viel Zeit kostet und langweilig ist, neigen die Leute dazu, es zu vermeiden. Und es würde die Zeit der Entwickler verschwenden. Das zu erreichen, kann sehr kompliziert sein, aber es gibt diverse Posts, die dieses Thema behandeln. Generell müssen Sie jeden Schritt nachverfolgen, diejenigen auswählen, die die meiste Zeit benötigen, und sie kontinuierlich verbessern.

• Sorgen Sie frühzeitig für Code-Quality-Checks und automatisierte Tests. Wenn man mit einem neuen Projekt beginnt, ist es verlockend einfach so schnell wie möglich mit der Entwicklung von Features zu beginnen. Das beeindruckt alle Stakeholder und macht am meisten Spaß. Aber das Testing schon zu Beginn zu ignorieren, führt bald zu Problemen. Sobald die Anwendung eine bestimmte Größe und Komplexität erreicht, ist es unvermeidlich auf Testautomatisierung zu setzen. Sie müssen die Arbeit sowieso machen, aber wenn Sie spät anfangen, wird es zunehmend schwieriger. Erstellen Sie also Tests vom ersten Tag an und fügen Sie sie der CI-Pipeline hinzu. Das Gleiche gilt für Code-Quality-Checks - je früher Sie beginnen, desto besser.

Schnelles Feedback vs. Production-like Environment

Wir werden später detaillierter auf die Deployment-Pipeline eingehen - im Moment ist es wichtig zu verstehen, was dabei passiert und wofür das gut ist. Hier ist eine passende Definition von devops.com:

Die (Deployment-)Pipeline unterteilt den Software-Delivery-Prozess in Stages. Jede Stage zielt darauf ab, die Qualität neuer Funktionen aus einem anderen Blickwinkel zu überprüfen, die neue Funktionalität zu validieren und zu verhindern, dass Fehler Ihre Benutzer beeinträchtigen.

Hier ist ein Diagramm, das eine grundlegende Deployment-Pipeline zeigt, die ein guter Ausgangspunkt für mittelgroße Projekte sein kann:

Wie Sie sehen, durchläuft ein Softwarepaket mehrere Stages, bevor es in der Produktion ankommt. Jede Stage hat einen bestimmten Grund, den wir in einem meiner zukünftigen Blogposts diskutieren werden. Ohne im Detail zu diskutieren, was in den einzelnen Stages passiert, gilt es zwei wichtige Punkte zu wissen und zu beachten:

1. Geschwindigkeit ist zu Beginn der Pipeline entscheidend. So sollte eine Erweiterung der lokalen Entwicklungsumgebung innerhalb von 5 Minuten abgeschlossen sein. Die Commit-Stage, die die Deliverables erstellt und die Unit-Tests erneut auf einer unabhängigen Maschine ausführt, sollte in weniger als 10 Minuten abgeschlossen sein, wobei 5 Minuten oder weniger optimal wären. Dies ist wichtig, da der Entwickler hier sofortiges Feedback erhalten muss. Er sollte abwarten können, ob sein Check-in funktioniert oder etwas kaputt gemacht hat. Wenn die ersten Stufen zu lange dauern, gefährdet dies den gesamten Prozess. Später werden Deployment und Tests länger dauern, da die Tests immer komplexer werden und die Integration zunimmt.
2. Je näher die Pipeline an der Produktionsumgebung ist, desto ähnlicher muss die Umgebung der tatsächlichen Production sein. Das ist wichtig, da dies das Fehlerrisiko beim Deployment in die Production verringert. Beginnend mit einzelnen lokalen Entwicklungsumgebungen erhöht jede Stage die Integration, weitere Komponenten werden hinzugefügt und komplexere Tests werden ausgeführt (siehe Testpyramide im vorherigen Post). Im besten Fall ist die letzte Stufe vor der Production (fast) gleich wie die Produktionsumgebung. Denn wenn die Deployments und Tests dort funktionieren, ist die Wahrscheinlichkeit sehr hoch, dass das Deployment in der Produktionsumgebung ebenfalls funktioniert.

Automatisieren Sie so viel wie möglich

Es besteht eine direkte Beziehung zwischen dem Automatisierungsgrad (oder der Menge an manuellen Aufgaben) und dem Geschäftserfolg. Es ist erstaunlich. Der Puppet DevOps Report beschreibt die Beziehung hier genauer: https://puppet.com/resources/whitepaper/state-of-devops-report. Unternehmen, die in Bezug auf die Automatisierung eine hohe Leistung erbringen, werden ihre Ziele doppelt so häufig erreichen wie durchschnittliche oder schwächere Unternehmen. Leistungsstarke Unternehmen automatisieren mehr als 75% aller Build- und Deployment-Aufgaben und reduzieren die Anzahl der manuellen Aufgaben erheblich.

Es gibt eine Grundregel für die Automatisierung von Aufgaben in der IT: Wenn Sie es zweimal tun müssen, denken Sie darüber nach, die Aufgabe zu automatisieren. Wenn Sie sie ein drittes Mal tun müssen, automatisieren Sie es.

Automatisierung sollte zumindest in diesen Bereichen eingeführt werden:

• Build und Deployment (offensichtlich)
• Testen (natürlich), Code Quality Checks und Reporting
• Einrichten von Build Tools
• Einrichten von Umgebungen zum Ausführen der Anwendung
• Setup der Entwicklungsumgebung

Die Schwierigkeiten bei der Implementierung von Automatisierung bestehen darin, dass es immer mit der Implementierung neuer Features konkurriert. Daher ist es nicht ratsam zu viel Zeit auf einmal mit dem Automatisieren manueller Aufgaben zu verbringen, da die Kapazität des Teams für die Implementierung von Features mit Business Value dadurch reduziert wird. Es ist besser, den Automatisierungsgrad kontinuierlich zu erhöhen, angefangen beim wichtigsten. Daher versuchen wir normalerweise, jedem Sprint CI/CD-Tasks oder allgemeine Automatisierungs-Tasks hinzuzufügen.

Etwas ist kaputt? Reparieren Sie es! Jetzt!

Das ist naheliegend, aber es ist auch die eine Regel, die viel zu oft ignoriert wird. Das Wichtigste bei CI/CD ist, dass es immer in einem funktionierenden Zustand ist. Wenn also ein Teil des Prozesses fehlschlägt, muss jemand (derjenige, der den Fehler verursacht hat am besten) sich sofort darum kümmern. Wenn der Check-in den Build unterbricht, beheben Sie ihn oder machen Sie ihn rückgängig. Wenn die Testausführung fehlschlägt, überprüfen Sie den Fehler sofort und beheben Sie entweder den Test oder den getesteten Code.

Versuchen Sie, alle Ihre CI/CD-Schritte so oft wie möglich auszuführen (mehrere Male am Tag wäre am besten). Erstens: Wenn Sie etwas häufig und regelmäßig tun, wird es einfacher. Zweitens: Wenn Sie täglich integrieren, werden die Änderungen die Fehler verursachen könnten, klein und leicht zu verstehen. Das macht es einfacher, Probleme zu beheben. Wenn Sie zu lange warten und eine große Menge an Code auf einmal einchecken, wird es immer schwieriger Fehler zu lokalisieren.

Beginnen Sie mit der Messung Ihrer Delivery-Prozesse

Sie können nicht kontrollieren, was Sie nicht messen können - Tom DeMarcos berühmtes Zitat gilt für Ihren Delivery-Prozess genauso, wie es für alles andere gilt. Denn woher wissen Sie, ob Sie erfolgreich sind oder ob es eine gute Investition war, wenn Sie beginnen CI/CD in Ihren Delivery-Prozess einzuführen?

Bevor Sie beginnen, definieren Sie einige KPIs, messen Sie diese und definieren Sie Zielwerte als Ergebnis der Verbesserungen aufgrund von CI/CD. Dies gibt Ihnen die Möglichkeit, Ihren Erfolg zu messen und der Geschäftsleitung die Wichtigkeit Ihrer Arbeit zu beweisen. Lassen Sie mich Ihnen einen kurzen Überblick über die wichtigsten KPIs für die Softwareentwicklung geben (wir werden Qualitätsmetriken hier überspringen, da das für sich selbst ein großes Thema ist):

Lead- und Cycle Time

Lead und Cycle Time sind die wichtigsten KPIs wenn es darum geht, den Delivery-Prozess zu messen – denn es dreht sich alles darum wie lange es dauert, ein Feature an die Kunden auszuliefern. Hier ist die Definition, die wir verwenden (es gibt natürlich viele verschiedene...):

Lead Time: Die Lead-Time-Clock beginnt mit der Anfrage und endet mit der Auslieferung.

Cycle Time: Die Cycle Time-Uhr startet, wenn die Arbeit an einer Feature-Anforderung beginnt und endet, wenn das Item zur Auslieferung bereit ist.

Wenn es nur um CI/CD geht, ist die Cycle Time ziemlich interessant. Auch wenn Ihr Unternehmen bereits eine Art von Delivery-Pipeline eingerichtet hat, kann es verwendet werden, um die Cycle Time ziemlich gut zu messen. Abgesehen davon können Tools wie Jira helfen, die Zeit zu messen, die eine Story von der ersten Definition bis zur Veröffentlichung in der Produktion benötigt. Wahrscheinlich haben Sie diese Informationen bereits irgendwo in den Tools versteckt, die Sie verwenden.

Team Velocity

Eine klassische agile Metrik - die Geschwindigkeit oder Velocity eines Teams. Beginnen wir mit dem Offensichtlichen: Man kann die Geschwindigkeit eines Teams nicht mit der eines anderen vergleichen. Das funktioniert wirklich nicht, also versuchen Sie es nicht. Aber es ist möglich, den Trend der Velocity eines Teams zu messen. Die Einführung von CI/CD wird sich zunächst negativ darauf auswirken, da Entwickler an der Automatisierung manueller Aufgaben arbeiten müssen. Aber insgesamt wird CI/CD die Geschwindigkeit Ihres Teams erheblich steigern und Velocity ist ein guter KPI, um diesen Anstieg zu zeigen.

Build- und Deployment-Metriken

Bei der Einführung von CI/CD sind diese Metriken wichtig, um den Erfolg der Initiative selbst zu messen. Weil CI/CD einen unmittelbaren und großen Einfluss auf Build- und Deployment-bezogene Metriken hat. Messen Sie sie also wenn Sie anfangen, setzen Sie sich ein Ziel und versuchen Sie, Schritt für Schritt darauf zuzugehen. Interessante KPIs sind:

• Anzahl der Builds pro Tag
• Anzahl der Build-Failures pro Tag
• Dauer des Builds, einschließlich automatisierter Tests
• Dauer pro Deployment-Stage
  

Sicherlich gibt es hier noch viel mehr zu diskutieren, zum Beispiel, ob es möglich ist, durch Einführung von CI/CD Geld zu sparen. Ich schreiben eventuell noch einen separaten Blogbeitrag über KPIs und Metriken für Software Delivery – wenn Sie vorab schon Interesse daran haben, mehr über dieses Thema zu erfahren, lassen Sie es mich wissen!