Continuous Integration auf den XP-Days 2009

XP-Days LogoLange Buildzeiten sind die Achillesferse des Continuous Integration-Gedankens – ein technischer Aspekt mit unmittelbarem Einfluss auf die Projektkultur. Praktisch jedes agile Team muss sich daher irgendwann der Frage stellen: „Wie schrumpfen wir den Build?“. Mein Vortrag auf den XP-Days 2009 (26.-28.11.2009, Karlsruhe) soll dazu Antworten geben.

Kurzbeschreibung der geplanten Vortrags:

Der Niedergang kam schleichend. Dabei hatte es so gut angefangen: Alle liebten Continuous Integration! Jede Codeänderung wurde innerhalb von Minuten bestätigt oder als fehlerhaft erkannt. Die Risiken wurden kleiner, die Entwickler gelassener, die Refactorings mutiger, die Software besser.

Dann wucherten die Buildzeiten – bis weit über die 2-Stunden-Marke hinaus. Das veränderte alles.

Der schnelle Kick blieb aus. Der Ritt vom Check-In zum Endorphin war längst dahin. Nur noch 4 „Schüsse“ pro Tag! Während der individuelle Beitrag im Rauschen der wenigen Builds verschwand, verendeten zunehmend Projekte an gebrochenen Builds. Kein Platz mehr für Ehre und Stolz, Mut und Selbstvertrauen. Kein Ort für Helden. Also wieder einchecken, zusammenpacken, heimgehen. Wie früher eben.

Lange Buildzeiten sind die Achillesferse des Continuous Integration-Gedankens – ein technischer Aspekt mit unmittelbarem Einfluss auf die Projektkultur. Praktisch jedes agile Team muss sich daher irgendwann der Frage stellen: „Wie schrumpfen wir den Build?

In der Präsentation werden wir daher Ansätze betrachten, die Buildzeiten verkürzen können. Diese Vorschläge umfassen sowohl „tiefhängende Früchte“, die also mit wenig Aufwand schnelle Erfolge bringen können, aber auch ausbaubare Lösungen, die etwas mehr an strategischer Investition erfordern. Wir werden…

  • modularisieren: Wie kann der Build aufgeteilt werden, so dass nicht immer alles komplett neu gebaut werden muss?
  • sequenzieren: Wie kann der Build gestaffelt werden, so dass die wichtigsten Erkenntnisse möglichst früh vorliegen?
  • parallelisieren: Wie kann der Build auf mehrere Rechner verteilt werden? Und warum ist diese einfache Idee in der Praxis fast immer kniffliger als erwartet?
  • streichen: Hand aufs Herz – was kann einfach weggelassen werden?

Die konkrete Umsetzung wird anhand einer durchgängigen Demo mit dem Continuous Integration System Hudson gezeigt. Natürlich dürfen dabei eXtreme-Feedback-Devices nicht fehlen…

Präsentation “Liebling, ich habe den Build geschrumpft!” (3,00 MB)

Kommentare


  • Keine Kommentare

Fragen, Kritik, Begeisterung? Hinterlassen Sie einen Kommentar!