Was ist kontinuierliche Integration

Software-Entwicklung ohne Verzögerungen

Kontinuierliche Integration ist eine Praktik

Kontinuierliche Integration ist etwas, das ein Team tut. Es bedeutet, dass alle Beiträge in Code oder anderen Artefakten von allen Teammitgliedern ständig in das Softwareprodukt integriert werden, während es immer mehr Funktionalität erhält. Es spielt keine Rolle, wie das Team dies tut. Es spielt keine Rolle, ob es einen Continuous-Integration-Server oder ein anderes Werkzeug mit „CI” im Namen gibt.

Sobald ein Teammitglied mit einem kleinen Beitrag fertig ist, wird dieser Beitrag integriert. Klein bedeutet etwas, das ein oder zwei Stunden gedauert hat. Klein ist nicht etwas, das länger als einen Tag oder sogar noch mehr dauert.

Keine Branches

Da Software durch das Schreiben von Code entsteht und Code Text ist, benötigen wir ein Versionskontrollsystem, das es uns ermöglicht, Text von verschiedenen Autoren einfach zusammenzuführen. Um kontinuierliche Integration zu praktizieren, brauchen wir keine Branches und schon gar kein System, das gut und schnell beim Branching ist. Tatsächlich wollen wir überhaupt keine Branches.

Branches bedeuten, dass das Softwaresystem mehrfach existiert und jede Version unterschiedlich ist. Das wollen wir nicht. Wir wollen nur die eine und einzige aktuelle Version des Systems.

Das heißt, es ist nichts falsch an einem lokalen Branch für das eine oder andere Experiment. Aber beachten Sie, dass Sie in dem Moment, in dem Sie einen Branch erstellen, effektiv aufgehört haben, kontinuierliche Integration zu praktizieren. Sie können Ihre eigene Arbeit auch lokal in einem Branch erledigen, wenn Sie sich damit sicherer fühlen oder unsicher sind, ob Sie den Code aus diesem Branch verwenden möchten. In dem Moment, in dem Sie die Ergebnisse Ihrer Arbeit teilen möchten, integrieren Sie Ihren neuen Code in die eine und einzige Hauptlinie der Codebasis.

Lokales und automatisiertes Testen

Wenn wir kontinuierliche Integration praktizieren, wollen wir sicherstellen, dass wir das System mit unserem neuen Code nicht kaputt machen. Deshalb nutzen wir lokale und automatisierte Tests, um sicherzustellen, dass alles noch funktioniert, bevor wir unseren neuen Code teilen.

Wir holen uns die neueste Version des Systems aus der Versionskontrolle, integrieren dann unsere Arbeit und unterziehen schließlich das Ganze einem Test.

Da es unmöglich ist, das gesamte System manuell zu testen, brauchen wir aussagekräftige automatisierte Tests, die auch angemessen schnell laufen. Idealerweise wollen wir, dass das gesamte System in ein oder zwei Minuten getestet wird, aber definitiv in weniger als 10 Minuten. Dieser Prozess sollte ausreichen, um sich frisches Wasser oder Kaffee zu holen, aber nicht genug, um neue Arbeit zu beginnen oder durch eine andere Aktivität abgelenkt zu werden.

Ist ein großer zentraler CI-Server erforderlich?

Im Jahr 2024 sind Entwickler-Arbeitsplätze oder Laptops so leistungsfähig, dass sie häufig Maschinen übertreffen, die als Server verwendet werden. Während in der Vergangenheit kontinuierliche Integration mit einem zentralen CI-Server verbunden war, der spezielle Software für Integrations-Builds ausführte — zum Beispiel Jenkins oder GitHub Actions — ist die Realität, dass CI grundlegend eine Praktik ist, kein Werkzeug.

Ein zentraler Build-Server kann nützlich sein, um die vollständige Testsuite auszuführen, nachdem Code gepusht wurde, um Release-Artefakte zu erstellen oder um Qualitätstore durchzusetzen, bevor Code in die Produktion gelangt. Aber die Kernpraktik der kontinuierlichen Integration findet am Arbeitsplatz des Entwicklers statt: den neuesten Code holen, Ihre Änderungen integrieren, die Tests lokal ausführen und erst pushen, wenn alles erfolgreich durchläuft.

Die wichtigste Erkenntnis ist, dass es bei kontinuierlicher Integration darum geht, die Zeit zwischen dem Schreiben von Code und dem Entdecken von Integrationsproblemen zu reduzieren. Ob das auf dem Laptop eines Entwicklers oder einer Serverfarm passiert, ist zweitrangig. Was zählt, ist, dass Integration häufig stattfindet — mehrmals täglich — und dass Feedback schnell kommt.

Der geschäftliche Wert kontinuierlicher Integration

Wenn Teams kontinuierliche Integration effektiv praktizieren, ergeben sich mehrere wichtige Vorteile:

Probleme tauchen sofort auf. Wenn Sie Ihre Arbeit mehrmals täglich mit der Arbeit anderer integrieren, erscheinen Inkompatibilitäten innerhalb von Stunden nach ihrer Entstehung. Sie werden behoben, während der Kontext noch frisch und die Änderung klein ist.

Keine Integrationsphase. Traditionelle Ansätze beinhalten Wochen paralleler Entwicklung, gefolgt von einer schmerzhaften „Integrationsphase”, in der alles zusammenkommt. Bei CI gibt es keine Integrationsphase, weil Integration kontinuierlich ist.

Immer auslieferbar. Weil die Codebasis immer in einem integrierten Zustand ist und alle Tests bestehen, können Sie jederzeit ausliefern. Diese Flexibilität ist von unschätzbarem Wert, wenn sich geschäftliche Anforderungen ändern.

Reduziertes Risiko. Kleine, häufige Integrationen bedeuten kleine, handhabbare Risiken. Wenn etwas kaputt geht, wissen Sie genau, was sich geändert hat, und können es schnell beheben.

Häufige Missverständnisse

„Wir machen CI, weil wir GitHub Actions verwenden.” Ein CI-Werkzeug zu verwenden bedeutet nicht, dass Sie kontinuierliche Integration praktizieren. Wenn Entwickler in langlebigen Branches arbeiten und erst nach Tagen oder Wochen zusammenführen, machen Sie kein CI, unabhängig davon, welche Werkzeuge Sie verwenden.

„CI bedeutet, Tests automatisch auszuführen.” Automatisiertes Testen ist für CI unerlässlich, aber es ist nicht dasselbe. CI dreht sich um das Integrationsmuster — den Rhythmus kleiner, häufiger Beiträge vom gesamten Team.

„Wir können kein CI machen, weil unsere Tests zu langsam sind.” Langsame Tests sind ein zu lösendes Problem, kein Grund, CI aufzugeben. Investieren Sie in schnellere Tests, parallelisieren Sie Ihre Testsuite oder identifizieren Sie, welche Tests lokal laufen können versus auf einem Server.

Das Wesen der kontinuierlichen Integration ist einfach: Jeder integriert seine Arbeit häufig, mindestens täglich. Diese einfache Disziplin, konsequent angewendet, verwandelt Software-Entwicklung von einem Hochrisiko-Glücksspiel in einen vorhersehbaren, nachhaltigen Prozess.