Eine Einführung in die Best Practices von CI / CD

Kontinuierliche Integration, Bereitstellung und Bereitstellung, zusammenfassend als CI / CD bezeichnet, ist ein wesentlicher Bestandteil der modernen Entwicklung mit dem Ziel, Fehler bei der Integration und Bereitstellung zu reduzieren und gleichzeitig die Projektgeschwindigkeit zu erhöhen. CI / CD ist eine Philosophie und eine Reihe von Vorgehensweisen, die häufig durch robuste Tools ergänzt werden, bei denen das automatisierte Testen in jeder Phase der Software-Pipeline im Vordergrund steht. Durch die Einbeziehung dieser Ideen in Ihre Praxis können Sie den Zeitaufwand für die Integration von Änderungen für ein Release verringern und jede Änderung gründlich testen, bevor Sie sie in die Produktion überführen.

CI / CD bietet viele potenzielle Vorteile, eine erfolgreiche Implementierung erfordert jedoch häufig eine Menge Überlegungen. Die Entscheidung, wie die Tools genau verwendet werden sollen und welche Änderungen in Ihren Umgebungen oder Prozessen erforderlich sind, kann ohne umfangreiche Versuche und Irrtümer eine Herausforderung darstellen. Obwohl alle Implementierungen unterschiedlich sind, können Sie durch Einhaltung der Best Practices häufig auftretende Probleme vermeiden und Verbesserungen schneller erreichen.

In diesem Handbuch werden einige grundlegende Anleitungen zur Implementierung und Wartung eines CI / CD-Systems vorgestellt, die den Anforderungen Ihres Unternehmens am besten entsprechen. Wir werden eine Reihe von Vorgehensweisen behandeln, mit denen Sie die Effektivität Ihres CI / CD-Service verbessern können. Lesen Sie sich die Informationen bitte schriftlich durch oder fahren Sie mit den Bereichen fort, die Sie interessieren.

CI / CD-Pipelines Hilfe Schäfer wechselt durch automatisierte Testzyklen, heraus Staging-Umgebungen und schließlich zur Produktion. Je umfassender Ihre Test-Pipelines sind, desto sicherer können Sie sich darauf verlassen, dass Änderungen keine unvorhergesehenen Nebenwirkungen in Ihre Produktionsbereitstellung einbringen. Da jedoch jede Änderung diesen Prozess durchlaufen muss, ist es unglaublich wichtig, Ihre Pipelines schnell und zuverlässig zu halten, um die Entwicklungsgeschwindigkeit nicht zu beeinträchtigen.

Die Spannung zwischen diesen beiden Anforderungen kann schwierig auszugleichen sein. Es gibt einige einfache Schritte, mit denen Sie die Geschwindigkeit verbessern können, z. B. die Skalierung Ihrer CI / CD-Infrastruktur und die Optimierung von Tests. Im Laufe der Zeit können Sie jedoch gezwungen sein, kritische Entscheidungen über den relativen Wert verschiedener Tests und die Phase oder Reihenfolge, in der sie ausgeführt werden, zu treffen. Manchmal ist das Reduzieren Ihrer Testsuite durch Entfernen von Tests mit geringem Wert oder mit unbestimmten Schlussfolgerungen der intelligenteste Weg, um die Geschwindigkeit aufrechtzuerhalten, die für stark ausgelastete Pipelines erforderlich ist.

Stellen Sie bei diesen wichtigen Entscheidungen sicher, dass Sie die Kompromisse, die Sie eingehen, verstehen und dokumentieren. Wenden Sie sich an Teammitglieder und Stakeholder, um die Annahmen des Teams darüber abzustimmen, wofür die Testsuite verantwortlich ist und welche Hauptschwerpunkte gesetzt werden sollten.

Unter dem Gesichtspunkt der Betriebssicherheit stellt Ihr CI / CD-System eine der wichtigsten zu schützenden Infrastrukturen dar. Da das CI / CD-System vollständigen Zugriff auf Ihre Codebasis und Anmeldeinformationen hat, um sie in verschiedenen Umgebungen bereitzustellen, ist es wichtig, diese zu sichern, um interne Daten zu schützen und die Integrität Ihrer Site oder Ihres Produkts zu gewährleisten. Aufgrund seines hohen Werts als Ziel ist es wichtig, Ihr CI / Ihre CD so weit wie möglich zu isolieren und zu sperren.

CI / CD-Systeme sollten in internen, geschützten Netzwerken bereitgestellt werden, die keiner externen Partei zugänglich sind. Es wird empfohlen, VPNs oder andere Technologien zur Netzwerkzugriffskontrolle einzurichten, um sicherzustellen, dass nur authentifizierte Bediener auf Ihr System zugreifen können. Abhängig von der Komplexität Ihrer Netzwerktopologie muss Ihr CI / CD-System möglicherweise auf mehrere verschiedene Netzwerke zugreifen, um Code in verschiedenen Umgebungen bereitzustellen. Wenn sie nicht ordnungsgemäß gesichert oder isoliert sind, können Angreifer, die Zugriff auf eine Umgebung erhalten, möglicherweise island hop ausführen, eine Technik, mit der der Zugriff durch Ausnutzung milderer interner Netzwerkregeln erweitert wird, um durch Schwachstellen in Ihrem CI / CD Zugriff auf andere Umgebungen zu erhalten Server.

Die erforderlichen Isolations- und Sicherheitsstrategien hängen stark von Ihrer Netzwerktopologie, Ihrer Infrastruktur sowie Ihren Verwaltungs- und Entwicklungsanforderungen ab. Der wichtige Punkt, den Sie berücksichtigen sollten, ist, dass Ihre CI / CD-Systeme äußerst wertvolle Ziele sind und in vielen Fällen einen breiten Zugriff auf Ihre anderen wichtigen Systeme haben. Das Abschirmen des gesamten externen Zugriffs auf die Server und die strikte Kontrolle der zulässigen internen Zugriffsarten tragen dazu bei, das Risiko einer Gefährdung Ihres CI / CD-Systems zu verringern.

Mit CI / CD können Sie unter anderem Ihre Entwicklungspraktiken und die Codequalität verbessern, indem Sie mithilfe von Tools häufig Best Practices für Tests und die Bereitstellung durchsetzen. Um Code über Ihre CI / CD-Pipelines zu promoten, müssen Sie bei jeder Änderung nachweisen, dass sie den kodifizierten Standards und Verfahren Ihres Unternehmens entspricht. Fehler in einer CI / CD-Pipeline sind sofort sichtbar und verhindern das Vorrücken der betroffenen Version in spätere Phasen des Zyklus. Dies ist ein Gatekeeping-Mechanismus, der die wichtigeren Umgebungen vor nicht vertrauenswürdigem Code schützt.

Um diese Vorteile zu realisieren, müssen Sie jedoch diszipliniert vorgehen, um sicherzustellen, dass jede Änderung an Ihrer Produktionsumgebung Ihre Pipeline durchläuft. Die CI / CD-Pipeline sollte der einzige Mechanismus sein, mit dem Code in die Produktionsumgebung gelangt. Dies kann automatisch am Ende eines erfolgreichen Tests mit fortlaufenden Bereitstellungsverfahren oder durch eine manuelle Werbung für getestete Änderungen geschehen, die von Ihrem CI / CD-System genehmigt und zur Verfügung gestellt wurden.

Häufig beginnen Teams, ihre Pipelines für die Bereitstellung zu verwenden, machen jedoch Ausnahmen, wenn Probleme auftreten und der Druck besteht, sie schnell zu lösen. Auch wenn Ausfallzeiten und andere Probleme so schnell wie möglich behoben werden sollten, ist es wichtig zu verstehen, dass das CI / CD-System ein gutes Werkzeug ist, um sicherzustellen, dass Ihre Änderungen keine anderen Fehler verursachen oder das System weiter beschädigen. Wenn Sie Ihren Fix durch die Pipeline stellen (oder nur das CI / CD-System für das Rollback verwenden), wird auch verhindert, dass bei der nächsten Bereitstellung ein Ad-hoc-Hotfix gelöscht wird, der direkt auf die Produktion angewendet wurde. Die Pipeline schützt die Gültigkeit Ihrer Bereitstellungen, unabhängig davon, ob es sich um eine reguläre, geplante Version oder eine schnelle Lösung zur Behebung eines laufenden Problems handelt. Diese Verwendung des CI / CD-Systems ist ein weiterer Grund für die Arbeit an der Verknüpfung: # Halten Sie Ihre Pipelines schnell [Halten Sie Ihre Pipeline schnell].

CI / CD-Pipelines fördern Änderungen durch eine Reihe von Testsuiten und Bereitstellungsumgebungen. Änderungen, die die Anforderungen einer Stufe erfüllen, werden entweder automatisch bereitgestellt oder für die manuelle Bereitstellung in restriktiveren Umgebungen in die Warteschlange gestellt. Frühphasen sollen beweisen, dass es sich lohnt, weiter zu testen und die Änderungen näher an die Produktion heranzuführen.

Insbesondere für spätere Phasen hilft die möglichst genaue Reproduktion der Produktionsumgebung in den Testumgebungen sicherzustellen, dass die Tests genau widerspiegeln, wie sich die Änderung in der Produktion verhalten würde. Signifikante Unterschiede zwischen Staging und Produktion können die Freigabe problematischer Änderungen ermöglichen, die niemals als fehlerhaft beim Testen festgestellt wurden. Je mehr Unterschiede zwischen Ihrer Live-Umgebung und der Testumgebung bestehen, desto weniger messen Ihre Tests die Leistung des Codes bei der Veröffentlichung.

Einige Unterschiede zwischen Inszenierung und Produktion werden erwartet, aber es ist wichtig, sie handhabbar zu halten und sicherzustellen, dass sie gut verstanden werden. Einige Unternehmen verwenden https://www.digitalocean.com/community/tutorials/how-to-use-blue-green-deployments-to-release-software-sichere Anpassungblue-green-Implementierungen], um den Produktionsdatenverkehr zwischen zwei nahezu identischen Umgebungen auszutauschen Umgebungen, die zwischen Produktion und Inszenierung wechseln. Weniger extreme Strategien umfassten die Bereitstellung derselben Konfiguration und Infrastruktur von der Produktion bis zu Ihrer Staging-Umgebung, jedoch in reduziertem Umfang. Elemente wie Netzwerkendpunkte unterscheiden sich möglicherweise zwischen Ihren Umgebungen. Durch die Parametrisierung dieser Art variabler Daten kann jedoch sichergestellt werden, dass der Code konsistent ist und die Umgebungsunterschiede genau definiert sind.

Ein primäres Ziel einer CI / CD-Pipeline ist es, das Vertrauen in Ihre Änderungen zu stärken und das Risiko unerwarteter Auswirkungen zu minimieren. Wir haben die Wichtigkeit der Aufrechterhaltung der Parität zwischen Umgebungen erörtert, aber eine Komponente davon ist wichtig genug, um zusätzliche Aufmerksamkeit zu verdienen. Wenn für Ihre Software ein Schritt zum Erstellen, Packen oder Bündeln erforderlich ist, sollte dieser Schritt nur einmal ausgeführt und die resultierende Ausgabe in der gesamten Pipeline wiederverwendet werden.

Diese Richtlinie hilft dabei, Probleme zu vermeiden, die auftreten, wenn Software mehrmals kompiliert oder gepackt wird, und ermöglicht es, geringfügige Inkonsistenzen in die resultierenden Artefakte einzufügen. Das separate Erstellen der Software in jeder neuen Phase kann bedeuten, dass die Tests in früheren Umgebungen nicht auf dieselbe Software abzielen, die später bereitgestellt wird, wodurch die Ergebnisse ungültig werden.

Um dieses Problem zu vermeiden, sollten CI-Systeme einen Erstellungsprozess als ersten Schritt in die Pipeline aufnehmen, der die Software in einer sauberen Umgebung erstellt und verpackt. Das resultierende Artefakt sollte versioniert und in ein Artefaktspeichersystem hochgeladen werden, um von nachfolgenden Phasen der Pipeline heruntergefahren zu werden. Dabei muss sichergestellt werden, dass sich der Build im Verlauf des Systems nicht ändert.

Obwohl es ein großes allgemeines Ziel ist, die gesamte Pipeline schnell zu halten, sind Teile Ihrer Testsuite zwangsläufig schneller als andere. Da das CI / CD-System als Kanal für alle Änderungen in Ihrem System dient, ist es wichtig, Fehler so früh wie möglich zu erkennen, um den Ressourcenaufwand für problematische Builds zu minimieren. Um dies zu erreichen, priorisieren Sie zuerst Ihre schnellsten Tests und führen Sie sie aus. Speichern Sie komplexe Tests mit langer Laufzeit, bis Sie den Build mit kleineren Tests mit kurzer Laufzeit validiert haben.

Diese Strategie hat eine Reihe von Vorteilen, die dazu beitragen können, dass Ihr CI / CD-Prozess in Ordnung bleibt. Es unterstützt Sie dabei, die Auswirkungen einzelner Tests auf die Leistung zu verstehen, ermöglicht es Ihnen, die meisten Tests frühzeitig abzuschließen, und erhöht die Wahrscheinlichkeit schneller Ausfälle. Dies bedeutet, dass problematische Änderungen rückgängig gemacht oder behoben werden können, bevor die Arbeit anderer Mitglieder blockiert wird.

Testpriorisierung bedeutet normalerweise, zuerst die Komponententests Ihres Projekts auszuführen, da diese in der Regel schnell, isoliert und komponentenorientiert sind. Anschließend stellen Integrationstests in der Regel die nächste Stufe der Komplexität und Geschwindigkeit dar, gefolgt von systemweiten Tests und schließlich Akzeptanztests, die häufig ein gewisses Maß an menschlicher Interaktion erfordern.

Eines der Hauptprinzipien von CI / CD besteht darin, Änderungen früh und häufig in das primäre gemeinsam genutzte Repository zu integrieren. Dies hilft, kostspielige Integrationsprobleme zu vermeiden, wenn mehrere Entwickler versuchen, große, abweichende und widersprüchliche Änderungen in den Hauptzweig des Repositorys zu integrieren, um die Veröffentlichung vorzubereiten. In der Regel überwachen und testen CI / CD-Systeme die Änderungen, die nur für einen oder mehrere Zweige festgelegt wurden.

Um die Vorteile von CI zu nutzen, sollten Sie die Anzahl und den Umfang der Zweigstellen in Ihrem Repository begrenzen. Bei den meisten Implementierungen wird davon ausgegangen, dass Entwickler sich mindestens einmal täglich direkt für die Hauptniederlassung verpflichten oder Änderungen aus ihren lokalen Niederlassungen zusammenführen.

Im Wesentlichen enthalten Zweige, die nicht von Ihrem CI / CD-System verfolgt werden, nicht getesteten Code, der als eine Gefahr für den Erfolg und die Dynamik Ihres Projekts angesehen werden sollte. Die Minimierung der Verzweigung, um die frühzeitige Integration des Codes verschiedener Entwickler zu fördern, hilft dabei, die Stärken des Systems zu nutzen, und verhindert, dass Entwickler die Vorteile, die es bietet, negieren.

Im Zusammenhang mit dem früheren Punkt zur Früherkennung von Fehlern sollte den Entwicklern empfohlen werden, möglichst viele Tests vor Ort auszuführen, bevor sie ein Commit für das freigegebene Repository ausführen. Auf diese Weise können bestimmte problematische Änderungen erkannt werden, bevor andere Teammitglieder blockiert werden. Während es unwahrscheinlich ist, dass die lokale Entwicklerumgebung die gesamte Testsuite in einer produktionsähnlichen Umgebung ausführen kann, gibt dieser zusätzliche Schritt Einzelpersonen mehr Sicherheit, dass die vorgenommenen Änderungen grundlegende Tests bestehen und es sich lohnt, die Integration in die größere Codebasis zu versuchen.

Um sicherzustellen, dass Entwickler selbst effektiv testen können, sollte Ihre Testsuite mit einem einzigen Befehl ausgeführt werden können, der in jeder Umgebung ausgeführt werden kann. Derselbe Befehl, den Entwickler auf ihren lokalen Computern verwenden, sollte vom CI / CD-System verwendet werden, um Tests für den im Repository zusammengeführten Code zu starten. Oft wird dies durch die Bereitstellung eines Shell-Skripts oder eines Makefiles koordiniert, um die Ausführung der Testtools auf wiederholbare, vorhersehbare Weise zu automatisieren.

Um sicherzustellen, dass Ihre Tests in verschiedenen Phasen gleich ablaufen, ist es oft eine gute Idee, wenn möglich saubere, kurzlebige Testumgebungen zu verwenden. In der Regel bedeutet dies, dass Tests in Containern ausgeführt werden, um Unterschiede zwischen den Hostsystemen auszugleichen und eine Standard-API zum Zusammenfügen von Komponenten in verschiedenen Maßstäben bereitzustellen. Da Container mit minimalem Status ausgeführt werden, werden verbleibende Nebenwirkungen von Tests nicht von nachfolgenden Durchläufen der Testsuite übernommen, die die Ergebnisse beeinträchtigen könnten.

Ein weiterer Vorteil von containerisierten Testumgebungen ist die Portabilität Ihrer Testinfrastruktur. Mit Containern können Entwickler die Konfiguration, die später in der Pipeline verwendet wird, einfacher replizieren, ohne die Infrastruktur manuell einrichten und warten oder die Umweltverträglichkeit beeinträchtigen zu müssen. Da Container bei Bedarf leicht aufgeschleudert und anschließend zerstört werden können, können Benutzer bei der Ausführung lokaler Tests weniger Kompromisse hinsichtlich der Genauigkeit ihrer Testumgebung eingehen. Im Allgemeinen werden Container-Sperren in einigen Aspekten der Laufzeitumgebung verwendet, um Unterschiede zwischen Pipeline-Phasen zu minimieren.

Obwohl jede CI / CD-Implementierung unterschiedlich ist, hilft Ihnen das Befolgen einiger dieser Grundprinzipien, einige häufige Fallstricke zu vermeiden und Ihre Test- und Entwicklungspraktiken zu verbessern. Wie bei den meisten Aspekten der kontinuierlichen Integration trägt eine Mischung aus Prozess, Werkzeug und Gewohnheit dazu bei, dass Entwicklungsänderungen erfolgreicher und effektiver werden.

Weitere Informationen zu allgemeinen CI / CD-Vorgehensweisen und zum Einrichten verschiedener CI / CD-Dienste finden Sie unter articles with the CI / CD-Tag.