Continuous Integration und Continuous Deployment verstehen

Sie haben CI/CD gehört, sind sich aber nicht sicher, was es ist?

Idealerweise werden Softwareingenieure eingestellt, um Code zu schreiben, der an eine Produktionsumgebung gesendet werden muss, damit das Unternehmen, das das Produkt benötigt, es nutzen kann. Um das Geschäft (oft als Benutzer/Kunden bezeichnet) zufrieden zu stellen, ist es wichtig, dass die Produkte fehlerfrei sind.

Der typische Ansatz von Softwareentwicklern besteht darin, in Branches zu arbeiten und eine Pull-Anforderung zu erstellen, die den Master-Branch mit dem neu erstellten Update aktualisiert. Wir haben die Praxis des Schreibens von Tests übernommen, um sicherzustellen, dass die neuen Änderungen keine Fehler einführen. Wenn Entwickler an einer Funktion arbeiten, erstellen sie in den meisten Fällen keine Pull-Anfrage, bis sie mit der Funktion vollständig fertig sind. Was passiert, wenn sie bereit sind, ist Folgendes;

• Sie verbringen viel Zeit damit, ihre Codebasis mit den Änderungen, die während ihrer Arbeit im Produktionszweig aufgetreten sind, auf den neuesten Stand zu bringen.
• Dabei müssen sie eine Reihe von Zusammenführungskonflikten beheben.
• Es besteht auch die Möglichkeit, dass sie den Produktionszweig unterbrechen, was sich auf diejenigen auswirkt, die aus dem Zweig ziehen, bevor das Problem erkannt und behoben wird.

Wenn Sie schon einmal in dieser Situation waren, werden Sie zustimmen, dass es ein Schmerz sein kann – niemand verbringt seinen Arbeitstag gerne so.

Was ist die Lösung?

Kontinuierliche Integration

Um die oben genannten Szenarien zu verhindern; Engineering-Teams können die als kontinuierliche Integration bezeichnete Praxis übernehmen – wie der Name schon sagt, beinhaltet sie die kontinuierliche Integration von Codeänderungen, die von Entwicklern in den gemeinsam genutzten Zweig/das Repository vorgenommen werden. Der zu integrierende Code muss einem verifizierten Test unterzogen werden, um sicherzustellen, dass er die Anwendung nicht beschädigt. Erst wenn der Test bestanden ist, wird er integriert

Um dies zu verstehen, stellen wir uns ein reales Szenario vor, in dem es ein Team von 10 Entwicklern gibt. Diese Entwickler erstellen lokal einen Zweig, in dem sie Code für die Implementierung bestimmter Funktionen schreiben. Anstatt Pull-Requests zu senden, wenn sie mit der Funktion fertig sind, entscheiden sie sich dafür, Pull-Requests zu senden, wenn sie kleine Änderungen vornehmen. Ein Beispiel für eine solche Änderung ist die Erstellung eines neuen Modals, vorausgesetzt, der Entwickler arbeitet an einer Funktion, mit der Benutzer einzelne Aufgaben in der Anwendung verwalten können. Anstatt zu warten, bis die Aufgabenfunktion abgeschlossen ist, um ein kontinuierliches Integrationsmuster einzuhalten, drückt der Entwickler diese kleine Änderung (im Vergleich zu dem, woran er arbeitet) und erstellt eine Pull-Anfrage, um sie mit dem Code zusammenzuführen.

Bevor diese neue Änderung integriert wird, müssen eine Reihe von Tests durchgeführt werden.

Software-Engineering-Teams nutzen Tools wie Travis C.I um diese Integrationsprozesse und Tests zu erstellen. Mit solchen Tools werden die Tests automatisiert, sodass sie ausgeführt werden, sobald eine Pull-Anforderung an den während der Einrichtung ausgewählten Ziel-Branch gesendet wird.

Die Ergebnisse der Tests werden generiert, und der Entwickler, der die Pull-Requests erstellt hat, kann die Ergebnisse sehen und notwendige Änderungen vornehmen. Die Vorteile, sich an dieses Muster zu halten, Code so wenig wie möglich zu integrieren und einen verifizierten Test zum Ausführen zu haben, sind:

• Dem beteiligten Team wird es möglich zu wissen, was dazu geführt hat, dass der Build-Prozess oder Test fehlgeschlagen ist. Dadurch wird die Wahrscheinlichkeit verringert, dass ein Fehler an die Produktion gesendet wird.
• Wenn das Team den Prozess automatisiert, haben sie den Luxus, sich auf die Produktivität zu konzentrieren.

Bei dieser Vorgehensweise ist es wichtig zu beachten, dass sie das Team dazu ermutigt, Code häufig in den Hauptzweig zu pushen. Dies ist wirkungslos, wenn andere Mitglieder des Teams nicht vom Hauptzweig ziehen, um ihr lokales Repository zu aktualisieren.

Arten von Tests

Beim Schreiben von Tests, die Teil des Integrationsprozesses sein werden, sind hier einige, die in den Prozess implementiert werden können:

• Integration – es kombiniert einzelne Einheiten der Software und testet sie als Gruppe.
• Einheit – testet auf einzelne Einheiten oder Komponenten der Software wie Methoden oder Funktionen.
• UI – behauptet, dass die Software aus Sicht des Benutzers gut funktioniert.
• Akzeptanz – testet, ob die Software den geschäftlichen Anforderungen entspricht.

Es ist wichtig zu beachten, dass Sie nicht alle davon testen müssen, da einige davon möglicherweise bereits im vom Entwickler geschriebenen Code enthalten sind.

Kontinuierliche Integrationswerkzeuge

Ohne in die Tiefe zu gehen, hier sind Tools, die Sie in Ihren aktuellen oder neuen Projekten einsetzen können;

• Travis C.I – in der Open-Source-Welt bekannt und verspricht Ihnen, Ihren Code in wenigen Minuten nahtlos zu testen.
• Kreis CI – bietet Ihnen Leistung, Flexibilität und Kontrolle, um Ihre Pipeline von der Kontrolle bis zur Bereitstellung zu automatisieren.
• Jenkins – stellt Hunderte von Plugins bereit, um das Erstellen, Bereitstellen und Automatisieren von Projekten zu unterstützen.

Wenn Sie neu bei Jenkins sind, würde ich vorschlagen, dies zu nehmen Udemy-Kurs CI mit Java und .NET zu lernen.

Kontinuierliche Bereitstellung

Was nützt es, wenn das von Ihnen erstellte Feature wochen- oder monatelang im Repository bleibt, bevor es in der Produktionsumgebung bereitgestellt wird. So sehr Engineering-Teams darauf hinarbeiten können, kleine Änderungen zeitnah in den Hauptzweig zu integrieren, können sie diese Änderungen auch so schnell wie möglich in die Produktionsumgebung übertragen.

Das Ziel beim Praktizieren von Continuous Deployment ist es, die vorgenommenen Änderungen an die Benutzer weiterzugeben, sobald die Entwickler diese Änderungen in den Hauptzweig integrieren.

Wie bei der kontinuierlichen Integration werden auch bei der Nutzung von Continuous Deployment automatisierte Tests und Prüfungen eingerichtet, um sicherzustellen, dass die neu integrierten Änderungen verifiziert werden. Die Bereitstellung erfolgt nur, wenn diese Tests erfolgreich sind.

Damit ein Team von der Praxis des Continuous Deployment profitieren kann, muss Folgendes vorhanden sein:

• Automatisiertes Testen ist das wesentliche Rückgrat aller kontinuierlichen Engineering-Praktiken. Im Falle einer kontinuierlichen Bereitstellung muss der bereitzustellende Code dem Standard entsprechen, den das Team für das, was es den Endbenutzern zur Verfügung stellen möchte, aufgestellt hat. Wenn eine neue Änderung unter dem Schwellenwert liegt, sollte der Test im Idealfall fehlschlagen und nicht integriert werden. Andernfalls wird es integriert.
• Trotz automatisierter Tests hintereinander ist es möglich, dass sich einige Fehler in die Produktionsumgebung einschleichen. Dazu ist es notwendig, dass das Team eine vorgenommene Änderung rückgängig machen kann – also ein Deployment rückgängig machen kann. Dies sollte den Produktionscode auf den Stand vor der neuen Änderung zurücksetzen.
• Überwachungssysteme sind erforderlich, um Änderungen zu verfolgen, die in die Produktionsumgebung übertragen wurden. Auf diese Weise kann das Team Fehler verfolgen, auf die Benutzer stoßen, wenn sie die bereitgestellten Änderungen verwenden.

Die genannten Tools zur Continuous Integration bieten Ihnen auch die Funktionalität, ein Continuous Deployment System aufzubauen. Es gibt viele davon, die Sie auch nachlesen können.

Fazit

Die Produktivität eines Entwicklungsteams ist entscheidend für den Erfolg des Unternehmens. Um sicherzustellen, dass sie produktiv sind, müssen Praktiken eingeführt werden, die dies fördern. Continuous Integration und Deployment sind Beispiele für solche Praktiken.

Mit kontinuierlicher Integration können Teams täglich so viel Code wie möglich pushen. Wenn dies erreicht ist, wird es einfach, die neu hinzugefügten Änderungen so schnell wie möglich für den Benutzer bereitzustellen. Durch die Bereitstellung dieser Änderungen ist es möglich, Feedback von den Benutzern einzuholen. Am Ende wird das Unternehmen auf der Grundlage des erhaltenen Feedbacks innovativ sein, was für alle eine Win-Win-Situation darstellt.

Sie können auch lernen, wie Sie CI/CD skalieren und optimieren.

Wenn Sie ein Entwickler sind und daran interessiert sind, CI/CD zu lernen, dann sehen Sie sich dies an genialer Kurs.

Haben Sie den Artikel gerne gelesen? Wie wäre es mit der Welt zu teilen?