Continuous Integration noch immer nicht etabliert

Interview mit Armin Vogt, S&N AG

Armin VogtWas ist Continuous Integration (CI)?

CI ist ein tool-gestützter Prozess: das Einchecken von Quellcode führt zu automatischem Übersetzen und Installieren der Gesamtlösung auf ein System. Tests prüfen das System auf seine Funktion. Fehlschläge sollen sofort Probleme erkennen lassen, die im Entwicklertest nicht erkannt wurden.

Wodurch zeichnen sich Projekte aus, die einen CI Prozess eingeführt haben?

Diese Projekte profitieren von einem weiteren virtuellen Teammitglied – dem Buildserver. Dieser baut und integriert automatisch den gesamten Quellcode und wirkt als neutrale Instanz. Wenn der Integrationstest fehlschlägt, lässt sich das leicht auf die Änderung im Quellcode zurückverfolgen. Dadurch enthält der zuständige Entwickler unmittelbar eine Rückmeldung auf die zu überarbeitenden Komponenten.

Muss dazu die sogenannte Testabdeckung einen signifikanten Umfang der Lösung testen?

Nicht unbedingt, denn selbst ohne Tests entstehen direkte Vorteile, weil Releases mit gleichbleibender Qualität und unbeeinflusst von Urlaubszeiten gebaut und installiert werden können. Ebenso können Tools zur statischen Codeanalyse eingesetzt werden. Sie entfernen Flüchtigkeitsfehler und zeigen beginnende Strukturschwächen im Code frühzeitig auf.

Wie viel Testabdeckung ist notwendig? Kann man das in Prozent angeben?

In vielen Projekten sind es nicht mehr als 10 Prozent. Entscheidend ist die Frage, welche 10 Prozent des Code abgedeckt werden. Hier ist die ABC-Analyse geeignet, bei der man alle Code-Teile gemäß ihrer Kritikalität in drei Klassen einteilt. Die Diskussion, ob genug Tests erstellt wurden, wird im Projekt nie entschieden. Interessanter ist die Frage, wie viel Zeit für die Erstellung von Tests eingeplant wird. Mein Vorschlag: 50% der geplanten Aufwände sollten für die Implementierung und Pflege von Tests bereitgestellt werden. Wenn man im Scrum-Verfahren plant und iteriert, sollte die Schätzung für jedes Feature verdoppelt werden. Das ist zwar erschreckend, aber realistisch.

CI gibt es nun schon seit über 15 Jahren. Ist es inzwischen ein alter Hut?

Ja. Die Tools sind da und sie sind sehr gut. Aber dennoch muss der für CI notwendige Aufwand immer wieder gerechtfertigt werden. Unsere Kunden lieben die Fähigkeiten der Tools und setzen sie dennoch nicht immer zielgerichtet und über einen längeren Zeitraum ein. In unserer Beratung stoßen wir deshalb immer auch den nötigen Umdenkprozess an und machen auf versteckte Hemmnisse aufmerksam. CI und Testautomatisierung müssen von engagierten Projektmitarbeitern aufgebaut und gepflegt werden, dann muss man kontinuierlich daran arbeiten, die Begeisterung und Überzeugung im Team und bei der Projektleitung aufrecht zu halten. Die Architektur muss testbar sein, das Code-Design muss Tests unterstützen. Wenn man beim Programmieren nicht an die Tests denkt, wird man beim Schreiben des Tests auf unlösbare Probleme stoßen.

Ist CI alternativlos?

Ja. Denn selbst wenn ich ein erfahrenes Team habe, das langfristig an einem System und seiner Weiterentwicklung arbeitet, muss ich dieses bestmöglich unterstützen und vor den Konsequenzen der zu erwartenden Fehler bewahren. Und kontinuierlich zusammenarbeitende Teams werden immer seltener.

Wiege ich durch automatisierte Qualitätssicherung das Team und dessen Management in falsche Sicherheit ?

Ich glaube nicht, dass das Team leichtsinnig wird, nur weil die Tests schon grobe Schnitzer aufdecken. Es gehört sicherlich zu den Vorteilen, auch spät im Entwicklungsprozess noch Architekturentscheidungen korrigieren zu können. Hieraus beziehen alle agilen Methoden eben ihre Agilität. Das kann ich nur mit dem Sicherheitsnetz von automatischen Tests und kontinuierlicher Integration erreichen.

Vielen Dank!