Je kürzer die Integrationszyklen und je kleiner die Integrationseinheiten, desto effizienter. Fehler werden einfach und früh entdeckt und sind rasch behoben — vorausgesetzt, die Prozesse und Regeln sind definiert, weitgehend automatisiert, und sie werden eingehalten.
Eine Software wächst wie ein Baum Jahrring um Jahrring, Ast um Ast, Zweig um Zweig, Blatt um Blatt. Der Baum ist mit dem Wachsen bereits integriert, Zweige zusammenführen muss er nicht. Bei der Software müssen wir nach dem «Wachsen» erst noch integrieren und zusammenführen (merge). Dabei gilt: Je öfter, desto besser. Das ist eine praktische Erfahrung, über die Einigkeit besteht, unabhängig von Techniken und Projektgrössen.
Ein Skaleneffekt — sprich Einsparungen durch Bündelung mehrerer Änderungen und Erweiterungen zu einem grossen Integrationsvorhaben — tritt nicht ein. Das Gegenteil ist der Fall: Je grösser das Integrations- oder Mergepaket und je grösser die Zeitabstände, desto grösser der Gesamtaufwand. Wer’s auch nur ein einziges Mal gemacht hat, kennt die Gründe.
Integration enthält immer das Risiko zur Destabilisation des integrierten Systems: Das Integrieren fördert immer wieder Probleme zu Tage. Je kleiner die Integrationseinheit, desto leichter treten sie zu Tage und desto einfacher sind sie zu beheben. Nach jedem Integrationsschritt werden Tests gefahren — möglichst vollautomatisch. So weiss man für jeden Schritt, ob er erfolgreich war oder nicht. Tritt ein Fehler auf, ist er bei einer kleinen Integration unter den wenigen Änderungen rascher gefunden als bei einer Massenintegration, weil der potenzielle Fehlerraum viel kleiner ist: wenig betroffener Code, wenig Module, wenig Schnittstellen, ein oder nur wenige Entwickler. Diese sind noch voll in der Materie drin, haben den Code präsent, erinnern sich an Details und finden die Fehler rascher, als wenn sie erst Wochen oder gar Monate später nochmals in die Fehlersuche und den Code einsteigen müssen.
«Integrate and merge as often as possible» heisst im Extremfall «Continuous Integration», also fortlaufende Integration, die von den Exponenten des Extreme Programming, namentlich Kent Beck, propagiert wird. Wie eng man die Zeitintervalle und wie feingranular man die Integrationsheinheiten wählt, hängt von der Art und Grösse des Projekts ab. Unbestritten ist, dass kleine Zyklen und Einheiten vorteilhafter als grössere sind, die Praxis zeigt dies ganz deutlich.
Das bedeutet nun keinesfalls «sich durchwursteln». Ganz im Gegenteil. Integration — ob in kleinen oder grossen Schritten — funktioniert nur, wenn ein paar Voraussetzungen gegeben sind:
- Die Abläufe und Regeln sind klar definiert und werden von allen befolgt.
- Es gibt ein Stufenkonzept, das festhält, was auf welcher Stufe zu tun ist, und unter welchen Bedingungen ein Modul auf die nächste Stufe vorrücken darf, und wer dieses Vorrücken («promote») auslösen darf.
- Es ist möglichst viel automatisiert, besonders die Builds und das Testen.
Wer fortlaufend integriert, arbeitet diszipliniert und methodisch, und er setzt Werkzeuge ein, die ihm erlauben, möglichst viel zu automatisieren. Ohne effiziente Werkzeuge funktioniert die fortlaufende Integration nicht.
Kleine Integrationsschritte wandeln die Integration und das Zusammenführen von einer lästigen, ermüdenden und schier endlosen Tortur zu einem eleganten Instrument für Fortschrittskontrolle und Qualitätssicherung. Genau diese Erfahrung findet sich auch in der anschaulichen, lesenswerten und praxisnahen Darstellung der Continuous Integration von Martin Fowler.
Weitere Beiträge in der Best-Practices-Reihe:
(9): Kennzahlen – Grundlage für Prozessverbesserungen
(8): Plan your environment carefully
(7): Structure for distributed development
(6): Baselines — die sichere Basis
(5): Change-Pakete bilden
(4): Merge and Integrate as often as possible
(3): Wiederherstellbarkeit
(2): Private Arbeitsbereiche
(1): Forget One-Size-Fits-All SCM / Design Scaleable Best Practices
