CI / CD gehört, aber nicht sicher, was es ist?
Im Idealfall werden Softwareentwickler beauftragt, Code zu schreiben, der an eine Produktionsumgebung gesendet werden muss, damit das Unternehmen, das das Produkt benötigt, davon Gebrauch machen kann. Um das Geschäft zufrieden zu stellen (oft als Benutzer / Kunden bezeichnet), ist es wichtig, dass die Produkte fehlerfrei sind.
Der typische Ansatz von Softwareentwicklern besteht darin, in Zweigen zu arbeiten und eine Pull-Anforderung zu erstellen, die den Hauptzweig mit dem neu vorgenommenen Update aktualisiert. Wir haben die Praxis des Schreibens von Tests übernommen, um sicherzustellen, dass die neuen Änderungen keine Fehler verursachen. Wenn Entwickler in den meisten Fällen an einem Feature arbeiten, erstellen sie häufig erst dann eine Pull-Anforderung, wenn sie mit dem Feature vollständig fertig sind. Was passiert, wenn sie bereit sind, ist das;
- Sie verbringen viel Zeit damit, ihre Codebasis mit den Änderungen auf dem neuesten Stand zu halten, die während der Arbeit in der Produktionsbranche aufgetreten sind.
- Dabei müssen sie eine Reihe von Zusammenführungskonflikten beheben.
- Es besteht auch die Möglichkeit, dass sie den Produktionszweig brechen, was sich auch auf diejenigen auswirkt, die aus dem Zweig ziehen, bevor das Problem erkannt und behoben wird.
Wenn Sie jemals in dieser Situation waren, werden Sie zustimmen, dass es ein Schmerz sein kann - niemand verbringt seinen Arbeitstag gerne so.
Was ist die Lösung?
Continuous Integration
Um die oben genannten Szenarien zu verhindern; Ingenieurteams können die aufgerufene Praxis übernehmen kontinuierliche integration - Wie der Name schon sagt, werden Codeänderungen, die von Entwicklern vorgenommen wurden, kontinuierlich in den gemeinsam genutzten Zweig / das gemeinsam genutzte Repository integriert. Der zu integrierende Code muss einem verifizierten Test unterzogen werden, um sicherzustellen, dass die Anwendung nicht beschädigt wird. Erst wenn der Test bestanden ist, wird er integriert
Um dies zu verstehen, stellen wir uns ein reales Szenario vor, in dem ein Team von 10 Entwicklern besteht. Diese Entwickler erstellen lokal einen Zweig, in den sie Code für die Implementierung bestimmter Funktionen schreiben. Anstatt Pull-Anfragen zu senden, wenn sie mit der Funktion vollständig fertig sind, entscheiden sie sich dafür, Pull-Anfragen zu senden, da sie nur geringe Ä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ängt der Entwickler auf diese kleine Änderung (im Vergleich zu dem, woran er gerade arbeitet) und erstellt eine Pull-Anforderung zum Zusammenführen mit dem Code.
Bevor diese neue Änderung integriert wird, müssen eine Reihe von Tests ausgeführt werden.
Software-Engineering-Teams nutzen Tools wie Travis CI 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 des Setups ausgewählten Zielzweig gesendet wird.
Die Ergebnisse der Tests werden generiert, und der Entwickler, der die Pull-Anforderungen erstellt hat, kann die Ergebnisse anzeigen und die erforderlichen Änderungen vornehmen. Die Vorteile, sich an dieses Muster zu halten, Code so wenig wie möglich zu integrieren und einen verifizierten Test ausführen zu lassen, sind:
- Das betroffene Team kann erkennen, warum der Erstellungsprozess oder Test fehlgeschlagen ist. Dies verringert die Möglichkeit, einen Fehler an die Produktion zu senden.
- Wenn das Team den Prozess automatisiert, hat es den Luxus, sich darauf zu konzentrieren, produktiv zu sein.
Das Wichtigste in dieser Praxis ist, dass das Team dazu ermutigt wird, Code häufig an den Hauptzweig zu senden. Dies ist unwirksam, wenn andere Mitglieder des Teams nicht aus dem Hauptzweig ziehen, um ihr lokales Repository zu aktualisieren.
Arten von Tests
Beim Schreiben von Tests, die Teil des Integrationsprozesses sein werden, können einige davon in den Prozess implementiert werden:
- Integration - Es kombiniert einzelne Einheiten der Software und testet sie als Gruppe.
- Einheit - Es werden einzelne Einheiten oder Komponenten der Software wie Methoden oder Funktionen getestet.
- Benutzeroberfläche - behauptet, dass die Software aus Sicht des Benutzers gut funktioniert.
- Akzeptanz - Testet, ob die Software den Geschäftsanforderungen entspricht.
Es ist wichtig zu beachten, dass Sie nicht alle testen müssen, da eine Handvoll davon möglicherweise bereits im vom Entwickler geschriebenen Code enthalten ist.
Kontinuierliche Integrationswerkzeuge
Hier sind Tools, die Sie in Ihren aktuellen oder neuen Projekten verwenden können, ohne auf die Tiefe einzugehen.
- Travis CI - in der Open-Source-Welt bekannt und verspricht Ihnen, Ihren Code in wenigen Minuten nahtlos testen zu lassen.
- Kreis CI - bietet Ihnen Leistung, Flexibilität und Kontrolle, um Ihre Pipeline von der Kontrolle bis zur Bereitstellung zu automatisieren.
- Jenkins - bietet Hunderte von Plugins zur Unterstützung beim Erstellen, Bereitstellen und Automatisieren von Projekten.
Wenn Sie neu in Jenkins sind, würde ich vorschlagen, dies zu nehmen Udemy natürlich CI mit Java und .NET zu lernen.
Continuous Deployment
Was nützt es, wenn die von Ihnen erstellte Funktion wochen- oder monatelang im Repository gespeichert wird, bevor sie in der Produktionsumgebung bereitgestellt wird. So sehr Engineering-Teams darauf hinarbeiten können, kleine Änderungen in den Hauptzweig zu integrieren, können sie diese Änderungen auch so schnell wie möglich in die Produktionsumgebung übertragen.
Das Ziel bei der Durchführung einer kontinuierlichen Bereitstellung besteht darin, die vorgenommenen Änderungen an die Benutzer weiterzuleiten, sobald die Entwickler diese Änderungen in den Hauptzweig integrieren.
Wie bei der kontinuierlichen Integration werden bei Verwendung der kontinuierlichen Bereitstellung automatisierte Tests und Überprüfungen eingerichtet, um sicherzustellen, dass die neu integrierten Änderungen überprüft werden. Die Bereitstellung erfolgt nur, wenn diese Tests bestanden wurden.
Damit ein Team von der Praxis des kontinuierlichen Einsatzes profitieren kann, muss Folgendes vorhanden sein:
- Automatisierte Tests sind das wesentliche Rückgrat aller kontinuierlichen Konstruktionspraktiken. Bei einer kontinuierlichen Bereitstellung muss der bereitzustellende Code dem Standard entsprechen, den das Team für das festgelegt hat, was es an Endbenutzer weitergeben möchte. Wenn eine neue Änderung unter dem Schwellenwert liegt, sollte der Test im Idealfall fehlschlagen und nicht integriert werden. Sonst wird es integriert.
- Trotz automatisierter Tests hintereinander ist es möglich, dass einige Fehler in die Produktionsumgebung gelangen. Dazu ist es erforderlich, dass das Team eine vorgenommene Änderung rückgängig machen kann - eine Bereitstellung rückgängig machen kann. Dadurch sollte der Produktionscode auf den Stand vor der neuen Änderung zurückgesetzt werden.
- Ü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 für die kontinuierliche Integration genannten Tools bieten Ihnen auch die Funktionalität zum Einrichten eines kontinuierlichen Bereitstellungssystems. Es gibt viele davon, die Sie auch können Lesen Sie weiter.
Fazit
Die Produktivität eines Entwicklungsteams ist entscheidend für den Erfolg des Unternehmens. Um sicherzustellen, dass sie produktiv sind, müssen Praktiken angewendet werden, die dies fördern. Kontinuierliche Integration und Bereitstellung sind Beispiele für solche Praktiken.
Durch die kontinuierliche Integration können Teams täglich so viel Code wie möglich übertragen. Dadurch wird es einfach, die neu hinzugefügten Änderungen so schnell wie möglich für den Benutzer bereitzustellen. Durch das Bereitstellen dieser Änderungen können Sie Feedback von den Benutzern erhalten. Am Ende wird das Unternehmen in der Lage sein, basierend auf dem erhaltenen Feedback Innovationen zu entwickeln, was für alle eine Win-Win-Situation darstellt.
Sie können auch lernen, wie es geht Hochskalieren und CI/CD optimieren.
Wenn Sie Entwickler sind und CI / CD lernen möchten, lesen Sie dies genialer kurs.
