Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
se:continuousintegration [2014-04-05 11:42] |
se:continuousintegration [2014-04-05 11:42] (aktuell) |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== Continuous Integration ====== | ||
+ | nach \cite{Read2009} | ||
+ | * Ziele: Qualität des Codes verbessern, Bugs frühzeitig finden und den Entwicklern die "Merge Hell" ersparen | ||
+ | * fördert Collective Code Ownership, da dem "runs on my machine" entgegengewirkt wird | ||
+ | * Tools alleine reichen nicht, die Entwickler müssen umdenken | ||
+ | * Methoden/Verfahren/Bausteine des CI | ||
+ | * Single Source Code Repository: Single Source of Truth | ||
+ | * automatisierter Build bei jedem Commit | ||
+ | * die IDE-Unterstützung ist kein automatisierter Build, da jeder Entwickler eine (leicht) andere Konfiguration hat | ||
+ | * der Commit sollte den Build direkt auslösen, damit nachvollziehbar ist, welche Änderungen den Build gebrochen haben | ||
+ | * man sollte häufig einchecken (und dadurch einen Build auslösen), um schnell Feedback zu den Änderungen zu bekommen (z.B. mind. 1x pro Stunde) | ||
+ | * vor dem Einchecken ist ein Update der Arbeitskopie nötig und ein kompletter lokaler Build muss erfolgreich durchlaufen, damit der Build-Server nicht mit vermeidbaren Problemen belastet wird; ein fehlerhafter lokaler Build darf nicht eingecheckt werden | ||
+ | * damit der Build schneller durchläuft, kann man den Build-Prozess parallelisieren (sog. "Build Chains", z.B. erst compile, dann test und javadoc parallel) | ||
+ | * automatisiertes Deployment: der Build sollte automatisch oder zumindest leicht automatisierbar auf die Produktionsmaschinen ausgerollt werden können |