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