Downloaden Sie, um offline zu lesen
Hochgeladen vonRalf Abramowitsch
Build Patterns - Patterns und Best Practices für den Build Prozess
Die Präsentation von Ralf Abramowitsch behandelt Best Practices und Patterns für Build-Konfigurationen, um den Entwicklungsprozess zu optimieren. Wichtige Themen sind die Trennung von statischen und dynamischen Build-Skripten, die Einführung von Build-Skeletten zu Projektbeginn und die Implementierung von gated commits zur Verbesserung der Code-Qualität. Ziel ist es, Wartbarkeit und Feedbackzeiten zu erhöhen sowie die Qualität im Entwicklungsprozess zu steigern.
Build Patterns - Patterns und Best Practices für den Build Prozess
- 1. Build Patterns BEST PRACTICESUND PATTERNS FÜR BUILD KONFIGURATIONEN
- 2. Ralf Abramowitsch Senior SoftwareDevelopment Engineer @ Vector Informatik GmbH Dozent: Software-Entwicklung mit .NET @ DHBW Stuttgart Kontakt E-Mail: ralf@abramowitsch.de Blog: http://blog.abramowitsch.de Twitter: @minibrain81
- 3. Agenda Einführung Build Patterns Build-Skelett Ablagen-unabhängige Build-Skripte Infrastruktur-unabhängigeBuild-Skripte Kumulative Builds Build Script Injection Gated Commits Zusammenfassung
- 4.
- 5. Einführung zu Patterns Patternswurden für architektonische Konzepte von Christopher Alexander et al. entwickelt. "Each pattern is a three-part rule, which expresses a relation between.. a problem, a certain context, and a solution" (Alexander et al. 1977). Patterns beschreiben Best Practices, erklären gute Designs, so dass diese Lösungen leicht wiederverwendet werden können. http://en.wikipedia.org/wiki/File:A_Pattern_Language.jpg
- 6. Einführung zu BuildPatterns Beautiful Builds Autor: Roy Osherove Aktueller Stand: 30% fertig https://leanpub.com/build
- 7.
- 8. Build Script Injection Problem CI-Prozessist etabliert und Produkte können gebaut werden Build-Abläufe sind in der Build-Konfiguration hinterlegt Build-Konfigurationen werden an aktuelle Anforderungen angepasst und immer gleich nachgezogen Alte Produktversion muss gebaut werden, zu der die neue BuildKonfiguration nicht passt Build schlägt fehl
- 9. Build Script Injection Projektstrukturzu Zeitpunkt A (Produktversion 1.0) Project 1 Bin Source Project 2 Projektstruktur zu Zeitpunkt B (Produktversion 2.0) Bin Source Project 1 Project 2 Bin Setup Source Utils Setup Utils
- 10. Build Script Injection Project1 Bin Source Project 2 Bin BuildKonfiguration Source Setup Utils Unter Versionskontrolle
- 11. Build Script Injection Lösung Aufteilender Build-Konfiguration in 2 Teile: Ein Script, das im Umfeld der Build-Konfiguration abgelegt ist Sehr statische und "dumme" Skripte Ein Script, das unter SourceCode-Verwaltung steht Script-Änderungen sind passend zur Produkt-Version Script ist passend zu Aktionen und zur aktuellen Struktur von Dateien (typischerweise relative Pfade) Entwickler sollten vollen Zugriff auf diese Skripte haben
- 12. Build Script Injection StatischerAnteil Dynamischer Anteil Project 1 Bin Source Project 2 BuildKonfiguration Bin Build-Skript Source Setup Utils Unter Versionskontrolle
- 13.
- 14. Build Skelette Problem Arbeiten aneinem Produkt laufen bereits auf Hochtouren Mit Buildautomatisierung wurde noch nicht oder nur teilweise begonnen Je weiter das Projekt voranschreitet, um so mehr Schritte müssen manuell vorgenommen werden und eine Build-Automatisierung wird immer schwerer
- 15. Build Skelette Lösung Zu Beginneines Projekts gleich mit der Buildautomatisierung beginnen Leeres Entwicklungsprojekt (z.B. Visual Studio Solution) anlegen Buildskript erstellen Leeres Test-Projekt erstellen und in CI-Prozess einbauen Deploy-Cycle einrichten
- 16. Build Skelette Vorteile Build-Prozess existiertvon Anfang an Einfach Anpassungen möglich Schnelles Feedback
- 17. Build Skelette Bestandteile des“Build Skeletts” Ein Build Skript (unter Versionskontrolle) zum Kompilieren des Quellcodes Continuous Integration Server Buildkonfiguration “CI”: Führt bei Code-Änderungen (Check-Ins) das Build-Skript aus Buildkonfiguration “Deploy”: Deploy-To-Test oder Deploy-To-Production
- 18.
- 19. Ablagen-unabhängige Skripte Problem Build-Skripte laufennur auf dem lokalen Rechner Inbetriebnahme eines CI-Systems wird sehr aufwändig Spezielle Build-Ordner Bibliotheken müssen an bestimmte Ordner kopiert werden Laufwerke mounten Etc. … Build-Skript hat spezielle Anforderungen an die Umgebung in der es ausgeführt wird
- 20. Ablagen-unabhängige Skripte Lösung Relative Pfadeanstelle absoluter Pfade Build-Skript steht unter Versionskontrolle (Repository) Bibliotheken, Tools usw. im (separaten) Repository
- 21.
- 22. Infrastruktur-unabhängige Skripte Problem Build-Skripte müssenan vielen Stellen angepasst werden, nur weil sich eine Stelle ändert Beispiele Name der Maschine, auf die deployed wird, ändert sich Neben Release-Targets sollen nun auch Debug-Targets gebaut werden Verletzung des „Single-Source“-Prinzips Name der Build-Konfiguration erscheint mehrfach im Skript
- 23. Infrastruktur-unabhängige Skripte Lösung Skript Variablen Beispiel:Name der Build-Konfiguration Skript Konfigurationsdatei Sammlung mehrerer Skript Variablen Vorteil: Alle Variablen an zentraler Stelle Umgebungsvariablen Skript Parameter
- 24. Infrastruktur-unabhängige Skripte Mögliche Seiteneffekte Erschwerendes Debuggens von Skript-Problemen Umgebungsvariablen müssen gut dokumentiert sein Lokaler Build könnte fehlschlagen, wenn nicht alle Voraussetzungen (Variablen, …) gesetzt sind
- 25.
- 26. Kumulative Builds Problem Builds dauernsehr lange, bis sie vollständig durchgelaufen sind Build-Konfiguration enthält zu viele Schritte Alle Schritte sind wichtig und können nicht übersprungen werden
- 27. Kumulative Builds Lösung Build-Konfigurationen sindoft ähnlich Erstellen einer Pipeline Wiederverwenden der Build-Artefakte
- 28. Kumulative Builds Ausgangssituation: ContinuousIntegration Build Source Code auschecken Debug Targets bauen Ausführen von Kurz-Tests auf Debug-Target
- 29. Kumulative Builds Ausgangssituation: NightlyBuild Source Code auschecken Debug Targets bauen Ausführen aller Tests auf Debug-Target Release Targets bauen Ausführen aller Tests auf Release-Target Erzeugen von CodeDoku, Installern, … Deployment auf Test-Umgebung
- 30. Kumulative Builds Ausgangssituation: ReleaseBuild Source Code auschecken Debug Targets bauen Ausführen aller Tests auf Debug-Target Release Targets bauen Ausführen aller Tests auf Release-Target Deployment auf ProductionUmgebung
- 31. Kumulative Builds Zielsituation: ContinuousIntegration Build Source Code auschecken Debug Targets bauen Ausführen von Kurz-Tests auf Debug-Target
- 32. Kumulative Builds Zielsituation: NightlyBuild Source Code auschecken Debug Targets bauen Ausführen von Kurz-Tests auf Debug-Target Build-Artefakte aus dem CIBuild hoen Release Targets bauen Ausführen aller Tests auf Release-Target Erzeugen von Installern Deployment auf Test-Umgebung
- 33. Kumulative Builds Zielsituation: ReleaseBuild Debug Targets bauen Ausführen von Kurz-Tests auf Debug-Target Holen der BuildArtefakte aus CI-Build Release Targets bauen Ausführen aller Tests auf Release-Target Holen der BuildArtefakte aus Nightly-Build Deployment auf ProductionUmgebung Source Code auschecken Erzeugen von CodeDoku, Installern, …
- 34.
- 35. Gated Commits Problem Entwickler wissennicht, was passiert, wenn sie ihren Code committen Bricht der Code den aktuellen Build? Funktionieren nach dem Commit noch alle Tests? „Blindes“ Committen
- 36.
- 37. Gated Commits Code schreiben „GatedCommit“ anfordern Entwickler Code Snapshot wird an Server übertragen Snapshot wird mit Master Source Version gemerged Build-Konfiguration wird ausgeführt Nein Benachrichtigung des Entwicklers Aufräumen & Bereitstellen von Logfiles etc. Build ok? Ja Code wird in Master Branch committed
- 38. Zusammenfassung Build Patterns undBest Practices optimieren den Build Prozess Erhöhte Wartbarkeit Kürzere Ausführungszeiten & schnelleres Feedback Erhöhte Qualität im Entwicklungsprozess
- 39. Vielen Dank fürIhre Aufmerksamkeit