Den Unterschied zwischen CI und CD verstehen: „Wenn etwas Schmerzen verursacht, tun Sie es öfter“

<sup>Haftungsausschluss . Kostis Kapelonis - Entwickler befürworten Codefresh, die erste CI / CD-Plattform für Kubernetes und Container, um die Prinzipien der Softwareentwicklung zu verteidigen und aufrechtzuerhalten. Codefreshs Mission „Automatisieren und vereinfachen Sie alles vom Code bis zur Cloud.“ Als Softwareentwickler verfügt Kostis über langjährige Erfahrung in der Containerisierung von Anwendungen, dem Erstellen von CI / CD-Pipelines und der Entwicklung von Java-Anwendungen. Er lebt in Griechenland und liebt Rollschuhlaufen.

Wie das Sprichwort sagt: "Wenn etwas Schmerzen verursacht, tun Sie es öfter." Kontinuierliche Integration ist im Wesentlichen eine Wiederholung des Integrationsschritts mit hoher Frequenz, um den dadurch verursachten „Schmerz“ zu lindern. In diesem Artikel geht es darum - um den "Schmerz" der Entwicklung und wie man ihn reduziert.</sup>

Es gibt viele Informationen zu Continuous Integration (CI) und Continuous Delivery (CD). Blog-Posts verwenden Fachbegriffe, um zu erklären, was CI / CD-Methoden bedeuten, was sie tun und wie sie Ihrem Unternehmen helfen können. Leider sind diese beiden Methoden häufig mit bestimmten Tools oder sogar Softwareanbietern verbunden. Ein typisches Gespräch zu diesem Thema in einem Unternehmen ist:

- Verwenden Sie eine kontinuierliche Integration in Ihr Team?
- Ja, natürlich benutzen wir Tool X!

Lass mich dir ein kleines Geheimnis verraten. Kontinuierliche Integration und Bereitstellung sind zwei Ansätze für die Codeentwicklung, die völlig unabhängig von einem bestimmten Tool oder Anbieter sind. Obwohl es Tools und Lösungen gibt, die Ihnen in beiden Fällen helfen können (z. B. Codefresh), kann ein Unternehmen in der Realität CI / CD nur mit Bash-Skripten und einzeiligen Perl-Skripten üben. Dies ist nicht sehr praktisch, aber durchaus möglich.

Anstatt in die allgemeine Falle zu tappen, das Wesentliche von CI / CD mithilfe von Tools und Fachbegriffen zu erklären, werden wir daher erklären, worauf diese Methoden auf dem wichtigsten Faktor im Entwicklungsprozess basieren - Menschen!

Die Geschichte der Menschen: Hard Times Software Integration

Treffen Sie Alice, Bob, Charlie, David und Elizabeth - alle arbeiten für SoftwareCo Inc. über das Erstellen der SuperBigProject-Anwendung. Alice, Bob und Charlie sind Entwickler. David ist Testingenieur und Elizabeth ist Teamprojektmanagerin.

Die traditionelle Art, eine Anwendung zu entwickeln, lautet wie folgt: Alice, Bob und Charlie arbeiten an drei verschiedenen Funktionen auf ihrer Workstation. Jeder Entwickler schreibt und testet den Code einzeln. Sie verwenden lange Funktionszweige, die mehrere Wochen oder sogar Monate bestehen, bevor sie zu einem Endprodukt kombiniert werden.



Irgendwann versammelt Projektmanagerin Elizabeth das gesamte Team und sagt: "Leute, wir müssen bereits eine Veröffentlichung veröffentlichen, also versuchen Sie es!"

Danach versuchen Alice, Bob und Charlie, alle drei Funktionen in einen Zweig zu integrieren. Dies ist eine sehr stressige Zeit, da diese Funktionen noch nie zusammen getestet wurden. Viele Fehler und Probleme treten aufgrund falscher Annahmen oder Probleme mit der Umgebung aus dem Nichts auf, denn wenn Sie sich erinnern, wurden bis zu diesem Zeitpunkt alle Funktionen einfach auf verschiedenen voneinander isolierten Arbeitsstationen getestet.

Sobald das „Integrationsfieber“ vorbei ist, wird das kombinierte Ergebnis an David weitergeleitet, der zusätzliche manuelle und automatische Tests durchführen wird. Dieser Zeitraum nimmt auch viel Zeit in Anspruch, da David die Freigabe genehmigen oder blockieren kann, je nachdem, wie viele kritische Fehler gefunden werden. Jeder beobachtet David genau, während er seinen Teil dazu beiträgt, da das Testen schwerwiegende Probleme aufdecken kann, die die Veröffentlichung des Produkts verzögern können.

Schließlich sind die Tests abgeschlossen und Elizabeth gibt freudig bekannt, dass das Softwareprodukt für Verpackung und Versand bereit ist.

Wie fühlen sich die Menschen in dieser imaginären, aber sehr realistischen Geschichte?

• Die Entwickler Alice, Bob und Charlie sind unglücklich, weil sie sich immer kurz vor der Veröffentlichung über Integrationsprobleme informieren. Die Integrationsperiode ähnelt einer Schießerei, bei der Kugeln gleichzeitig von allen Seiten eintreffen.
• Der Tester David ist ständig nervös wegen der "zuckenden" Natur seiner Arbeit - es gibt ruhige Zeiten, in denen er nur wartet, bis die Entwickler die Arbeit an den Funktionen beendet haben, und es gibt eine Testphase, in der er nur mit der Arbeit überfordert ist und sich mit unerwarteten Testskripten befassen muss, um Darüber hinaus steht zu diesem Zeitpunkt das Entwicklungsteam buchstäblich hinter ihm.
• Auch Elizabeth als Projektmanagerin ist unglücklich. Die Integrationsphase ist ein kritisches Bindeglied im Projekt. Dies ist eine arbeitsreiche Zeit, da jedes unerwartete Problem die Freigabe des Produkts vorantreibt. Elizabeth träumt von einer Softwareversion ohne Überraschungen, aber in der Praxis passiert dies nie. Der „Hit“ der Integrationsphase in der geplanten Zeitachse des Projekts ist immer ein Ratespiel.

Im Allgemeinen sind alle Teammitglieder unglücklich. Übrigens, wenn Ihr Unternehmen noch solche Software entwickelt, versuchen Sie zu verstehen, dass dieser Entwicklungsprozess die Moral Ihres Teams beeinträchtigt.

Das einzige und Hauptproblem ist hier also die Integrationsphase, die bei jeder Version des Softwareprodukts auftritt. Dies ist ein Schmerzpunkt im Workflow, der es einem Team von Programmierern nicht ermöglicht, sich von der mit der Veröffentlichung des Programms verbundenen Stresssituation zu befreien.

Kontinuität zur Integration hinzufügen

Nachdem wir gesehen haben, was „Integration“ bedeutet, ist es sehr leicht zu verstehen, was „kontinuierliche Integration“ bedeutet. Wie das Sprichwort sagt: "Wenn etwas Schmerzen verursacht, tun Sie es öfter." Kontinuierliche Integration ist im Wesentlichen eine Wiederholung des Integrationsschritts mit hoher Frequenz, um den dadurch verursachten „Schmerz“ zu lindern.

Der naheliegendste Weg, um den Prozess weniger schmerzhaft zu gestalten, besteht darin, nach jeder Zusammenführung häufiger zu integrieren, anstatt auf die offizielle Veröffentlichung zu warten.



Wenn ein Team eine kontinuierliche Integration praktiziert, dann:

• Alle Objekte werden direkt in den Hauptzweig eingefügt.
• Entwickler arbeiten zusammen, nicht isoliert. Alle Funktionen werden aus der Hauptleitung entwickelt.
• Eine Funktion gilt als entwickelt, wenn die Hauptleitung voll funktionsfähig ist und auf jedem Computer und nicht nur auf einer separaten Workstation funktioniert.
• Das Testen erfolgt automatisch sowohl auf der Ebene einzelner Elemente oder Codeobjekte als auch auf der Ebene der Hauptlinie.

Dies ist die Essenz einer kontinuierlichen Integration. Natürlich gibt es andere Nuancen dieser Methodik, es gibt ein ganzes Buch zu diesem Thema, aber die Hauptsache ist, dass anstelle einer einzigen stressigen Integrationsperiode, in der alles gleichzeitig zusammengeführt und getestet wird, die Integration kontinuierlich auf kontinuierliche Weise erfolgt.

Die kontinuierliche Integration in den Softwareentwicklungsprozess ist der herkömmlichen Integration überlegen, weil:

• Reduziert die Anzahl der Überraschungen, die beim Zusammenführen von Codeobjekten auftreten.
• Es löst das Problem "Das Programm funktioniert nur auf meinem Computer."
• Der Testzeitraum wird in mehrere Zeiträume aufgeteilt, in denen jedes Codeobjekt schrittweise mit der Hauptzeile zusammengeführt wird, anstatt alle Objekte gleichzeitig zusammenzuführen.

Infolgedessen fühlt sich das Team, das CI einsetzt, nicht wie eine Achterbahn, wenn ruhige Entwicklungsphasen mit stressigen Freisetzungen durchsetzt sind. Darüber hinaus hat sie die Möglichkeit, nüchtern zu beurteilen, wie kurz vor dem Abschluss des Projekts steht, anstatt die Veröffentlichungstermine zu erraten. Die Verwendung von CI ist eine der Säulen der modernen Softwareentwicklung. Heute ist diese Methode sehr gut dokumentiert und bekannt. Daher kann es keine Rechtfertigung dafür geben, dass Ihr Unternehmen CI bei der Entwicklung von Softwareprojekten immer noch nicht praktiziert.

Hard Times Software Delivery

Nachdem wir uns nun mit der Geschichte der regulären Integration und der Funktionsweise der kontinuierlichen Integration befasst haben, können wir diese auf die nächste Ebene des Entwicklungsprozesses bringen - die kontinuierliche Bereitstellung. Wenn wir zu unserer ursprünglichen Geschichte zurückkehren, sehen wir ein Bild, das dem Prozess der normalen Integration ähnelt:



Die Produkteinführung war im Wesentlichen eine Veranstaltung, die dem Urknall ähnelte. Nachdem die Software als getestet angesehen wurde, musste jemand den Prozess der Minimierung und Bereitstellung von Software aus Containern abschließen. Die Bereitstellung von Software in der Produktion war ebenfalls eine sehr arbeitsreiche Zeit und umfasste traditionell viele manuelle Schritte und Folgeverfahren. Bereitstellungen waren sehr selten, und bis heute gibt es Unternehmen, die dieses Verfahren nicht mehr als einmal alle sechs Monate durchführen. Nur in extremen Fällen erfolgte die Bereitstellung zu einem bestimmten Zeitpunkt - unter Verwendung des kaskadierenden Modells der Softwareentwicklung (Wasserfall).

Die Softwarebereitstellung erst nach Ablauf der Frist führt zu denselben Problemen wie regelmäßige, seltene Integrationen:

• Die Produktionsumgebung unterscheidet sich normalerweise von der Testumgebung, für die in letzter Minute eine zusätzliche Konfiguration erforderlich ist.
• Funktionen, die in einer Testumgebung normal funktionierten, werden in der Arbeitsumgebung unterbrochen.
• Funktionen, die zum Zeitpunkt der Veröffentlichung noch nicht bereit waren, werden den Kunden entweder überhaupt nicht zur Verfügung gestellt, oder ihre Verfeinerung treibt die Veröffentlichung noch weiter voran.
• In dieser Hinsicht erzeugen Releases Spannungen zwischen Entwicklern, die neue Funktionen hinzufügen möchten, um die Funktionalität der Software zu erweitern, und Betreibern, die Stabilität wünschen und nicht zu viele neue Funktionen gleichzeitig bereitstellen möchten.

Die Lösung für dieses Problem ist dieselbe Vorlage wie im Fall der Integration. Wenn wir den Schmerz des Integrationsprozesses lindern können, indem wir ihn häufiger machen, können wir dasselbe im Softwarebereitstellungsprozess tun.

Fügen Sie der Lieferung Kontinuität hinzu

Kontinuierliche Lieferung ist die Praxis, Verpackungen in Containern zu verpacken und Software so oft wie möglich so vorzubereiten, als würde sie an die Produktion gesendet. Die extremste Übermittlungsmethode ist nach jeder Zusammenführung.



Auf diese Weise geht CD CI noch einen Schritt weiter. Nach dem Zusammenführen jeder Funktion mit dem Hauptzweig wird die Anwendung nicht nur auf Richtigkeit überprüft, sondern auch gepackt und in einer Testumgebung bereitgestellt, die perfekt zur Arbeitsumgebung passt. All dies geschieht in einem vollautomatischen Modus - achten Sie auf das Fehlen in der Figur der kleinen Männer, die manuelle Verfahren anzeigen.

Denken Sie auch daran, dass jedes neue Feature ein potenzieller Kandidat für den Start in die Produktion ist. In der Praxis werden nicht alle Kandidaten zur Produktion geschickt. Abhängig von der Organisation des Prozesses erfordert die Entscheidung für die Bereitstellung in der Produktion manchmal das Eingreifen einer verantwortlichen Person, die entscheidet, ob die Freigabe in die Produktion freigegeben wird oder nicht, sich jedoch nicht persönlich an der Vorbereitung der Freigabe beteiligt. Zu diesem Zeitpunkt ist die Version bereits in einer Testumgebung gepackt, getestet und bereitgestellt.

Continuous Delivery (CD) ist etwas komplizierter als Continuous Integration (CI). Der Grund dafür ist, dass der gesamte Lebenszyklus automatisiert werden sollte, da jeder Release-Kandidat möglicherweise die Produktion erreichen kann:

• Baugruppen müssen wiederholbar und deterministisch sein.
• Alle Schritte müssen automatisiert werden, was in der Praxis nur schwer umzusetzen ist.
• Alle Konfigurations- und zugehörigen Dateien müssen im Versionskontrollsystem vorhanden sein und nicht nur im Quellcode.
• Jedes Feature / Release muss in einer eigenen dynamisch erstellten und dynamisch zerstörten Testumgebung getestet werden.
• Alle Testsuiten müssen automatisiert und relativ schnell sein, was ebenfalls keine leichte Aufgabe ist.

Obwohl eine „Cloud“ sicherlich dazu beitragen kann, all diese Anforderungen zu erfüllen, benötigt ein Team von Programmierern, sowohl Entwicklern als auch Betreibern, ein gewisses Maß an Disziplin, das den Prozess der kontinuierlichen Softwarebereitstellung wirklich sicherstellt.

Nach der Einführung der CD werden Veröffentlichungen zur Routine, als ob sie mit einem einfachen Klick auf eine Schaltfläche ausgeführt würden. Jedes Teammitglied, nicht nur der Projektmanager, kann den aktuellen Release-Kandidaten sehen. Dieser Kandidat verfügt möglicherweise nicht über einige erforderliche Funktionen oder erfüllt möglicherweise nicht alle Anforderungen. Dies ist jedoch absolut nicht wichtig, bis sich dies auf den Freigabeprozess selbst auswirkt.

Die wichtige Tatsache ist, dass die Version vollständig getestet, verpackt und bereit ist, bei Bedarf an die Produktion gesendet zu werden. Gleichzeitig sollte jeder Projektteilnehmer in der Lage sein, grünes Licht zu geben und Software sofort für die Produktion freizugeben.

Wenn Sie eine CD verwenden, kann der Software-Lebenszyklus wie folgt dargestellt werden:



Jeder Release-Kandidat wird immer im Voraus vorbereitet. Die Person entscheidet, ob der Release-Kandidat auch für die Produktion nominiert wird. Release-Kandidaten, die die Produktion nicht erreichen, werden weiterhin als Artefakte gespeichert, falls sie in Zukunft verwendet werden müssen.

Zu Ihrer Information, zur kontinuierlichen Bereitstellung sowie zur kontinuierlichen Integration, wurde auch ein ganzes Buch geschrieben, aus dem Sie die Details dieser Methodik herausfinden können.

Bonus: Kontinuierliche Bereitstellung

Der Buchstabe "D" auf der CD kann die Bereitstellung und nicht die Zustellung bedeuten. Diese Herangehensweise an den Entwicklungsprozess basiert auf einer kontinuierlichen Bereitstellung und eliminiert im Wesentlichen menschliche Eingriffe. Jeder Kandidat für die Freigabe, der alle Tests und Qualitätsprüfungen besteht und als bereit anerkannt wird, wird sofort an die Produktion gesendet.



Zugegeben, nur sehr wenige Unternehmen können auf diese Weise operieren. Die Förderung der Produktion ohne menschliches Eingreifen sollte nicht leicht genommen werden, da zum Zeitpunkt dieses Schreibens viele Unternehmen nicht einmal eine kontinuierliche Lieferung praktizieren, ganz zu schweigen von einer kontinuierlichen Bereitstellung.

Sie müssen verstehen, dass jeder nachfolgende Ansatz für den Entwicklungsprozess auf der Implementierung des vorherigen Ansatzes basiert.



Bevor Sie den Weg der Verbesserung beschreiten, muss Ihr Unternehmen sicherstellen, dass alle Grundlagen des Prozesses wirklich solide sind. Wir bei Codefresh haben viele Unternehmen gesehen, die beabsichtigten, auf Cloud-Technologien umzusteigen, und versuchten, ihre für die Verwendung in Rechenzentren auf CI / CD-Pipelines optimierten Technologien zu konvertieren, ohne zu bemerken, dass einige dieser Technologien heute veraltet sind. Der Versuch, eine kontinuierliche Bereitstellung bereitzustellen, ohne die kontinuierliche Bereitstellung vollständig zu übernehmen, ist zum Scheitern verurteilt.

Die folgende Abbildung zeigt, welche Phasen des Softwareentwicklungs- und -implementierungsprozesses von Alice, Bob, Charlie, David und Elizabeth CD und CI abdecken.



Stellen Sie sicher, dass Sie sich jedem Softwareentwicklungsparadigma in der richtigen Reihenfolge nähern. Glauben Sie, dass die Einführung der kontinuierlichen Bereitstellung ein sehr realistisches Ziel ist, für dessen Umsetzung alle erforderlichen Tools vorhanden sind.

Ein bisschen Werbung :)

Vielen Dank für Ihren Aufenthalt bei uns. Mögen Sie unsere Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud VPS für Entwickler ab 4,99 USD empfehlen. Dies ist ein 30% iger Rabatt für Habr-Benutzer auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s ab 20 US-Dollar oder wie man einen Server freigibt? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2 x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV ab 199 US-Dollar in den Niederlanden! Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über das Erstellen von Infrastruktur-Bldg. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?