Sie haben schon von CI/CD gehört, sind sich aber unsicher, was genau dahinter steckt?
Im Idealfall ist es die Aufgabe von Softwareentwicklern, Code zu schreiben, der in einer Produktionsumgebung bereitgestellt werden muss, damit das Unternehmen, das das Produkt benötigt, es auch nutzen kann. Um Kunden oder Benutzer zufriedenzustellen, ist es unerlässlich, dass die Produkte fehlerfrei sind.
Softwareentwickler arbeiten typischerweise in Branches und erstellen Pull-Anfragen, um den Haupt-Branch mit den neu entwickelten Updates zu aktualisieren. Es ist üblich, Tests zu schreiben, um zu gewährleisten, dass neue Änderungen keine Fehler verursachen. Oftmals erstellen Entwickler jedoch erst dann eine Pull-Anfrage, wenn eine Funktion vollständig abgeschlossen ist. Das kann zu folgenden Problemen führen:
- Es geht viel Zeit verloren, um die eigene Codebasis mit den Änderungen, die im Produktionsbranch während der Entwicklungsarbeit entstanden sind, zu synchronisieren.
- Dabei müssen etliche Merge-Konflikte gelöst werden.
- Außerdem besteht die Gefahr, dass der Produktionsbranch beschädigt wird, was sich wiederum auf andere Entwickler auswirkt, die aus dem Branch ziehen, bis das Problem gefunden und behoben ist.
Wenn Sie diese Situation kennen, stimmen Sie wahrscheinlich zu, dass das sehr lästig ist – so möchte niemand seinen Arbeitstag verbringen.
Wie lautet also die Lösung?
Kontinuierliche Integration
Um die oben genannten Szenarien zu vermeiden, können Entwicklerteams die Methode der kontinuierlichen Integration anwenden. Wie der Name schon sagt, werden dabei Codeänderungen von Entwicklern fortlaufend in den gemeinsam genutzten Branch oder das Repository integriert. Der Code muss dabei validierende Tests durchlaufen, um sicherzustellen, dass er die Anwendung nicht beschädigt. Erst nach erfolgreichen Tests erfolgt die Integration.
Um dies zu veranschaulichen, stellen wir uns ein Team von zehn Entwicklern vor. Diese Entwickler erstellen lokal einen Branch, um Code für spezifische Funktionen zu schreiben. Anstatt Pull-Anfragen erst nach Abschluss einer Funktion zu senden, entscheiden sie sich, diese nach kleineren Änderungen zu erstellen. Ein Beispiel hierfür wäre die Erstellung eines neuen Modals, während der Entwickler an einer Funktion zur Aufgabenverwaltung arbeitet. Anstatt zu warten, bis die Aufgabenfunktion abgeschlossen ist, integriert der Entwickler diese kleine Änderung, um dem Muster der kontinuierlichen Integration zu folgen, und sendet eine Pull-Anfrage zur Zusammenführung mit dem Code.
Vor der Integration dieser Änderung müssen diverse Tests durchgeführt werden.
Softwareentwicklungsteams nutzen Werkzeuge wie Travis C.I, um diese Integrationsprozesse und Tests zu erstellen. Diese Tools automatisieren die Tests und führen sie aus, sobald eine Pull-Anfrage an den ausgewählten Ziel-Branch gesendet wird.
Die Testergebnisse werden generiert und der Entwickler, der die Pull-Anfrage erstellt hat, kann diese einsehen und gegebenenfalls Änderungen vornehmen. Die Vorteile dieser Vorgehensweise, Code in kleinen Schritten zu integrieren und Tests zur Validierung zu haben, sind folgende:
- Das Team kann leicht nachvollziehen, was zu einem fehlgeschlagenen Build-Prozess oder Test geführt hat. Dadurch sinkt das Risiko, dass ein Fehler in die Produktionsumgebung gelangt.
- Durch die Automatisierung des Prozesses kann sich das Team auf seine Produktivität konzentrieren.
Es ist wichtig zu beachten, dass diese Methode zwar häufiges Pushen von Code in den Hauptbranch fördert, aber nicht effektiv ist, wenn Teammitglieder ihren lokalen Branch nicht aktualisieren.
Testarten
Bei der Erstellung von Tests für den Integrationsprozess können folgende Arten implementiert werden:
- Integrationstests – kombinieren einzelne Einheiten der Software und testen sie als Gruppe.
- Unit-Tests – testen einzelne Einheiten oder Komponenten der Software wie Methoden oder Funktionen.
- UI-Tests – stellen sicher, dass die Software aus Benutzersicht korrekt funktioniert.
- Akzeptanztests – prüfen, ob die Software die Geschäftsanforderungen erfüllt.
Es ist wichtig zu wissen, dass nicht alle Tests notwendig sind, da einige Aspekte möglicherweise bereits durch den vom Entwickler geschriebenen Code abgedeckt sind.
Werkzeuge für die kontinuierliche Integration
Ohne zu sehr ins Detail zu gehen, hier einige Werkzeuge, die Sie in Ihren aktuellen oder neuen Projekten verwenden können:
- Travis C.I – bekannt in der Open-Source-Welt und ermöglicht das Testen von Code in wenigen Minuten.
- Circle CI – bietet Leistung, Flexibilität und Kontrolle, um Ihre Pipeline von der Codekontrolle bis zur Bereitstellung zu automatisieren.
- Jenkins – stellt hunderte von Plugins zur Verfügung, um das Erstellen, Bereitstellen und Automatisieren von Projekten zu unterstützen.
Wenn Sie neu bei Jenkins sind, empfehle ich Ihnen den Udemy-Kurs, um CI mit Java und .NET zu lernen.
Kontinuierliche Bereitstellung
Was bringt es, wenn eine entwickelte Funktion wochen- oder monatelang im Repository verbleibt, bevor sie in der Produktionsumgebung bereitgestellt wird? So sehr Entwicklungsteams daran arbeiten, kleine Änderungen zeitnah in den Hauptbranch zu integrieren, sollten diese Änderungen auch so schnell wie möglich in die Produktionsumgebung gelangen.
Das Ziel von Continuous Deployment ist es, Änderungen an die Benutzer weiterzugeben, sobald die Entwickler sie in den Hauptbranch integrieren.
Wie bei der kontinuierlichen Integration sind auch beim Continuous Deployment automatisierte Tests und Überprüfungen eingerichtet, um sicherzustellen, dass die neu integrierten Änderungen verifiziert werden. Die Bereitstellung erfolgt nur bei erfolgreichen Tests.
Um von Continuous Deployment profitieren zu können, muss Folgendes gegeben sein:
- Automatisierte Tests sind die Grundlage aller kontinuierlichen Engineering-Methoden. Im Falle einer kontinuierlichen Bereitstellung muss der bereitzustellende Code den Qualitätsstandards entsprechen, die das Team für Endbenutzer definiert hat. Wenn eine neue Änderung diesen Standard nicht erfüllt, sollten die Tests fehlschlagen, sodass die Änderung nicht integriert wird.
- Trotz automatisierter Tests können Fehler in der Produktionsumgebung auftreten. Daher ist es wichtig, dass das Team die Möglichkeit hat, Änderungen rückgängig zu machen – also ein Deployment zurückzusetzen. Dadurch wird der Produktionscode auf den Stand vor der neuen Änderung zurückgesetzt.
- Überwachungssysteme sind wichtig, um Änderungen zu verfolgen, die in die Produktionsumgebung übertragen wurden. So kann das Team Fehler nachverfolgen, auf die Benutzer bei der Nutzung der bereitgestellten Änderungen stoßen.
Die bereits erwähnten Werkzeuge für die kontinuierliche Integration bieten auch Funktionen zum Aufbau eines Continuous Deployment-Systems. Es gibt viele weitere Tools, die Sie recherchieren können.
Fazit
Die Produktivität eines Entwicklungsteams ist entscheidend für den Erfolg eines Unternehmens. Um diese zu gewährleisten, müssen entsprechende Methoden eingeführt werden. Continuous Integration und Deployment sind dafür gute Beispiele.
Durch die kontinuierliche Integration können Teams täglich so viel Code wie möglich pushen. Wenn dies erreicht ist, wird es einfacher, neu hinzugefügte Änderungen so schnell wie möglich für die Benutzer bereitzustellen. Durch die Bereitstellung dieser Änderungen können Rückmeldungen von den Benutzern eingeholt werden. Das Unternehmen kann dann auf der Grundlage des Feedbacks innovativ sein, was eine Win-Win-Situation für alle Beteiligten darstellt.
Sie können auch lernen, wie man CI/CD skaliert und optimiert.
Wenn Sie als Entwickler daran interessiert sind, CI/CD zu lernen, empfehle ich Ihnen diesen großartigen Kurs.
Hat Ihnen der Artikel gefallen? Teilen Sie ihn gerne mit der Welt!