====== 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