„Continuous Integration“ (CI) ist ein Begriff, der immer mal wieder fällt. An dieser Stelle wollen wir uns ansehen, was dahinter steckt und inwiefern dieses Konzept uns bei der Auslieferung von qualitativ hochwertigem Code helfen kann.
Was ist die Idee von Continuous Integration?
Continuous Integration bedeutet, dass unser Code bei jeder Änderung gebaut und automatisch getestet wird. In der Praxis checkt jede Entwicklerin und jeder Entwickler den eigenen Code mindestens einmal in die Versionskontrolle ein. Jedes Mal, wenn neuer Code in das Repository eingecheckt wird, laufen automatisch verschiedene Prozesse los: Zunächst wird sichergestellt, dass der eingecheckte Code valide ist und keine offensichtlichen Fehler enthält. Hierfür wird ein Build-Prozess gestartet. Da Python eine interpretierte Sprache ist, muss hier nichts kompiliert werden.
Anschließend starten die automatischen Tests und prüfen, ob sich Querwirkungen ergeben haben. Das Ziel hierbei ist es, so früh wie möglich festzustellen, ob es Probleme mit dem aktuellen Codestand gibt. Sollte der Build scheitern oder sollten ein oder mehrere Tests fehlschlagen, so gilt es, diese Probleme sofort zu beheben, damit keine Folgefehler entstehen, die die Problembehebung noch schwieriger machen. Es gilt der Grundsatz: Die Kosten für die Behebung eines Fehlers steigen mit der vergangenen Zeit, die es braucht, um festzustellen, dass es einen Fehler gibt. Mit anderen Worten: Je früher Fehler erkannt und behoben werden, desto günstiger ist die Weiterentwicklung.
Was sind die Vorteile von Continuous Integration?
Neben den wirtschaftlichen Faktoren sind es vor allem psychische Elemente, die zu einer produktiveren Entwicklungsumgebung führen. Als Entwickler mache ich mir viel weniger Sorgen, etwas kaputtzumachen. Wenn ich mich an die Idee halte, so oft wie möglich den eigenen Code einzuchecken, dann sind die Änderungen, die ich mache, vergleichsweise gering. Sollten nun also Fehler auftauchen, dann kann ich diese relativ schnell beheben.
Darüber hinaus kann ich sicherstellen, dass mein Code nicht nur auf meiner Maschine läuft, sondern auch auf anderen Rechnern unter anderen Bedingungen.
Außerdem nimmt mir CI viel Arbeit ab, die ich ansonsten mit vielen Tests der Software verbringen müsste. Das bedeutet nicht, dass ich nicht mehr testen muss, aber ich kann mich auf diejenigen Tests konzentrieren, die nicht einfach vom Computer erledigt werden können und das sind üblicherweise die interessanteren Fälle.
Schließlich lassen sich die Änderungen sehr fein zurückverfolgen, so dass wahrscheinlich schnell klar wird, welche Änderung im Besonderen zu einem bestimmten Problem geführt hat. Somit wird auch hierdurch das Beseitigen eines Problems einfacher.
Haben wir also einen funktionierenden Continuous-Integration-Prozess aufgesetzt, können wir als Team selbstsicher agieren, indem wir eine Gewissheit haben, dass wir Code mit sehr wenigen Fehlern erzeugen. Das macht uns zufriedener und produktiver.
Das Ergebnis
Am Ende eines erfolgreichen Durchlaufs sollte ein fertiges Stück Software, ein Artefakt, bereitliegen. Dieses Artefakt wird dann weiter verarbeitet. Das kann beispielsweise sein, dass sich nun ein menschlicher Tester das Ganze vorknöpft und auf Herz und Nieren auf eine Art und Weise prüft, die sich durch automatische Tests nicht abbilden lassen. Oder das Artefakt wird gleich auf einem Testsystem zur Verfügung gestellt, so dass eventuell Abnahmetests erfolgen können.
Fazit
Ein gut aufgesetztes Continuous-Integration-Workflow ist im ersten Augenblick ein Aufwand, erspart aber im Nachgang so viel Zeit und psychische Reibung, dass es das Ziel jeder professionellen Software-Entwicklung sein sollte, CI einzusetzen.
Im Zusammenhang mit Continuous Integration fallen auch immer die Begriffe „Continuous Delivery“ und „Continuous Deployment“. Diese Konzepte gehören unbestreitbar zur Continuous Integration. Was sie im Detail bedeuten, schauen wir uns im nächsten Post an.
Photo by sergio souza on Unsplash