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:
- 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.
- 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.