Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:continuousintegration

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
se/continuousintegration.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)