Build ist der Schritt im SAFe for DevOps Health Radar, in dem committed Code kontinuierlich integriert, getestet und zu einem deploybaren Artefakt mit eingebauter Qualität verarbeitet wird. In diesem Video erkläre ich, was der Build-Schritt umfasst, warum Continuous Integration wichtig ist und wie Techniken wie Gated Commits und statische Sicherheitsanalyse helfen, Qualität bei hoher Geschwindigkeit aufrechtzuerhalten.
Vom committed Code zum deploybaren Artefakt#
Bevor wir den Build-Schritt erreichen, haben wir die früheren Stufen des SAFe for DevOps Health Radar durchlaufen. Alles beginnt mit Ideen vom Kunden oder Business. Wir formulieren Hypothesen, forschen gemeinsam, um das echte Kundenbedürfnis zu identifizieren, definieren die minimale Architektur und entwickeln eine Vision mit Roadmap und Features. Im Develop-Schritt brechen wir Features in User Stories herunter und implementieren sie.
Sobald der Code committed ist, beginnt der Build-Schritt. Das Ziel ist es, den committed Code mit dem Rest der Codebasis zu reintegrieren, Tests und Code-Analysen durchzuführen und ein deploybares Artefakt mit eingebauter Qualität zu erzeugen.
Continuous Integration#
Jeder Commit in die Versionskontrolle sollte einen automatisierten Prozess auslösen. Der Continuous Integration Server nimmt den neu committed Code, reintegriert ihn mit dem Rest der Codebasis und führt dann eine Reihe von Prüfungen durch:
- Build/Kompilieren des Codes zusammen mit dem Rest der Codebasis
- Unit Tests ausführen, um die Korrektheit auf Komponentenebene zu überprüfen
- Code-Analyse durchführen, um die Codequalität zu prüfen
- Sicherheits-Code-Analyse ausführen (statische Analyse), um Schwachstellen zu erkennen
Das zentrale Prinzip ist schnelles Feedback. Entwickler müssen so schnell wie möglich wissen, ob ihr committed Code in Ordnung war oder ob er Probleme eingeführt hat.
Das Problem mit langlebigen Branches#
Eine der häufigsten Problemquellen sind langlebige Branches. Teams arbeiten oft einen ganzen Sprint auf einem Branch und versuchen dann am letzten Tag, alles zu reintegrieren. Dieser Ansatz verursacht viele Probleme und ist selten erfolgreich.
Die Lösung ist, so schnell wie möglich zurückzumergen, damit es immer einen Branch gibt, der die aktuelle Version der Software enthält. Ob das Team Trunk-Based Development oder Git Flow verfolgt, ist seine Entscheidung. Wichtig ist, dass Code schnell zurückgemergt wird, damit Continuous Integration seine Aufgabe erfüllen kann.
Broken Builds und Gated Commits#
Ein Broken Build betrifft nicht nur das eigene Team, sondern auch andere Teams, die an derselben Codebasis arbeiten. Deshalb hat ein Broken Build immer die höchste Priorität und muss sofort behoben werden.
Eine Strategie, um Broken Builds von vornherein zu vermeiden, ist der Gated Commit. Bei Gated Commits nimmt der Build Server den neu committed Code und reintegriert ihn mit dem Rest der Codebasis, ohne ihn bereits in die Versionskontrolle zu committen. Dann wird der Code kompiliert, die Unit Tests ausgeführt, die Code-Analyse durchgeführt und die Sicherheitsanalyse ausgeführt. Nur wenn alles erfolgreich ist, committet der Build Server den Code in die Versionskontrolle. Falls etwas fehlschlägt, kommt der Code zurück mit einer Benachrichtigung. Diese Technik verhindert, dass Defekte jemals in die Haupt-Codebasis gelangen.
Application Security#
Statische Sicherheitsprüfungen sind ein wesentlicher Bestandteil des Build-Schritts. Unter dem Oberbegriff Application Security analysieren wir statisch nicht nur unseren eigenen Quellcode, sondern auch die Pakete und Bibliotheken, von denen wir abhängen. Eine Schwachstelle in irgendeiner Bibliothek in der Abhängigkeitskette kann zu einer Schwachstelle in unserer Anwendung werden. Automatisierte Sicherheits-Scan-Tools erkennen diese Probleme frühzeitig, bevor das Artefakt in die Produktion gelangt.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Build-Schritt:
- Sit: Builds werden weniger als einmal pro Iteration oder Sprint ausgeführt und sind komplett manuell.
- Crawl: Builds werden einmal pro Iteration oder Sprint ausgeführt und sind teilweise automatisiert. Dev-Branches sind über Monate oder länger offen und Builds brechen häufig.
- Walk: Automatisierte Builds laufen einmal täglich. Broken Builds werden in zwei bis vier Stunden behoben. Manuelle Unit Tests werden gegen jeden Build ausgeführt. Dev-Branches sind zwei bis vier Wochen offen.
- Run: Builds laufen automatisch bei jedem Code-Commit. Broken Builds werden innerhalb einer Stunde behoben. Automatisierte Unit Tests werden gegen jeden Build ausgeführt. Dev-Branches werden in jedem Sprint in den Trunk gemergt.
- Fly: Builds laufen bei jedem Commit. Builds beinhalten statische Code-Analyse und Sicherheitsanalyse. Gated Commits verhindern, dass Defekte in die Versionskontrolle gelangen. Dev-Branches werden bei jedem Commit in den Trunk gemergt.
Kernaussagen#
- Das Ziel von Build ist ein deploybares Artefakt mit eingebauter Qualität. Committed Code muss reintegriert, kompiliert, getestet und analysiert werden, bevor er zu einem Artefakt wird.
- Continuous Integration ist essenziell. Jeder Commit sollte automatisch einen Build, Unit Tests, Code-Analyse und Sicherheitsanalyse auslösen.
- Langlebige Branches vermeiden. So schnell wie möglich in den Haupt-Branch zurückmergen, um die Integration reibungslos zu halten.
- Broken Builds sofort beheben. Ein Broken Build hat die höchste Priorität, weil er das gesamte Team und andere Teams betrifft.
- Gated Commits nutzen, um Broken Builds zu verhindern. Der Build Server validiert den Code, bevor er in die Versionskontrolle gelangt.
- Application Security in den Build einbinden. Eigenen Code und alle Abhängigkeiten bei jedem Build auf Schwachstellen scannen.