Was ist der Unterschied zwischen diesen drei Begriffen? Meine Universität bietet folgende Definitionen:

Kontinuierliche Integration bedeutet im Grunde nur, dass die Arbeitskopien des Entwicklers mehrmals täglich mit einer gemeinsam genutzten Hauptleitung synchronisiert werden.

Continuous Delivery wird als logische Weiterentwicklung der kontinuierlichen Integration beschrieben: Immer in der Lage sein, ein Produkt in Produktion zu bringen!

Die kontinuierliche Bereitstellung wird als logischer nächster Schritt nach der kontinuierlichen Bereitstellung beschrieben: Stellen Sie das Produkt automatisch in der Produktion bereit, wenn es die Qualitätssicherung besteht!

Sie bieten auch eine Warnung: Manchmal wird der Begriff "Kontinuierliche Bereitstellung" auch verwendet, wenn Sie eine kontinuierliche Bereitstellung auf dem Testsystem durchführen können.

All das verwirrt mich. Jede Erklärung, die etwas detaillierter ist (oder ein Beispiel enthält), ist willkommen!

Kontinuierliche Integration

Ich stimme der Definition Ihrer Universität zu. Kontinuierliche Integration ist eine Strategie, mit der ein Entwickler Code kontinuierlich in die Hauptlinie integrieren kann - im Gegensatz zu häufig.

Sie könnten behaupten, dass es sich lediglich um eine Verzweigungsstrategie in Ihrem Versionskontrollsystem handelt.

Dies hängt mit der Größe der Aufgaben zusammen, die Sie einem Entwickler zuweisen. Wenn eine Aufgabe voraussichtlich 4 bis 5 Manntage dauert, hat der Entwickler keinen Anreiz, für die nächsten 4 bis 5 Tage etwas zu liefern, da er mit nichts fertig ist - noch nicht.

Größe ist also wichtig:

small task = continuous integration
big task   = frequent integration

Die ideale Aufgabengröße ist nicht größer als ein Arbeitstag. Auf diese Weise hat ein Entwickler natürlich mindestens eine Integration pro Tag.

Kontinuierliche Lieferung

Grundsätzlich gibt es drei Schulen innerhalb von Continuous Delivery:

Continuous Delivery ist eine natürliche Erweiterung von Continuous Integration

Diese Schule befasst sich mit der Addison-Wesley-Signaturserie "Martin Fowler" und geht davon aus, dass sie seit der Veröffentlichung von 2007 als "Continuous Integration" und die 2011 als "Continuous Delivery" bezeichnete Version wahrscheinlich Band 1 + 2 sind der gleichen konzeptuellen Idee, die mit kontinuierlichem etwas zu tun hat .

Continuous Delivery hat mit agiler Softwareentwicklung zu tun

Diese Schule widerspricht der Idee, dass es bei Continuous Delivery darum geht, die Prinzipien der agilen Bewegung zu unterstützen, nicht nur als konzeptionelle Idee oder Absichtserklärung, sondern für die Realität - im realen Leben.

Offset im ersten Prinzip des Agilen Manifests, wo der Begriff "kontinuierliche Lieferung" tatsächlich zum ersten Mal verwendet wird:

Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.

Diese Schule behauptet, dass "Continuous Delivery" ein Paradigma ist, das alles umfasst, was zur Implementierung einer automatisierten Überprüfung Ihrer "Definition von erledigt" erforderlich ist .

Diese Schule akzeptiert, dass "Continuous Delivery" und das Modewort oder der Megatrend "DevOps" Kehrseiten derselben Medaille sind, in dem Sinne, dass beide versuchen, dieses neue Paradigma oder diesen neuen Ansatz und nicht nur eine Technik anzunehmen oder zu verkapseln.

Continuous Delivery ist ein Synonym für Continuous Deployment

Die dritte Schule befürwortet, dass Continuous Deployment und Continuous Delivery austauschbar verwendet werden können, um dasselbe zu bedeuten.

Wenn etwas in den Händen der Entwickler bereit ist, wird es sofort an die Endbenutzer geliefert, was in den meisten Fällen bedeutet, dass es in der Produktionsumgebung bereitgestellt werden sollte. Daher bedeutet "Bereitstellen" und "Bereitstellen" dasselbe.

Welche Schule soll ich besuchen?

Ihre Universität ist eindeutig der ersten Schule beigetreten und behauptet, dass wir uns auf Band 1 + 2 derselben Publikationsreihe beziehen. Meiner Meinung nach ist dies ein Missbrauch des Begriffs "Kontinuierliche Lieferung".

Ich persönlich befürworte das Verständnis, dass Continuous Delivery mit der Implementierung einer realen Unterstützung für die Ideen und Konzepte der agilen Bewegung zusammenhängt. Also bin ich der Schule beigetreten, die besagt, dass der Begriff ein ganzes Paradigma umfasst - wie "DevOps".

Die Schule, die die Bereitstellung als Synonym für die Bereitstellung verwendet, wird hauptsächlich von Tool-Anbietern empfohlen, die Bereitstellungskonsolen erstellen und versuchen, ein wenig Hype durch die weiter verbreitete Verwendung des Begriffs " Kontinuierliche Bereitstellung" zu bekommen .

Kontinuierliche Bereitstellung

Der Fokus auf die kontinuierliche Bereitstellung ist hauptsächlich in Bereichen relevant, in denen der Zugriff des Endbenutzers auf Softwareupdates auf der Aktualisierung einer zentralen Quelle für diese Informationen beruht und in denen diese zentralisierte Quelle nicht immer einfach zu aktualisieren ist, da sie monolithisch ist oder (zu) hohe Kohärenz aufweist von Natur aus (Web, SOA, Datenbanken usw.).

Für viele Domänen, die Software produzieren, für die es keine zentrale Informationsquelle gibt (Geräte, Verbraucherprodukte, Client-Installationen usw.) oder für die die zentrale Informationsquelle einfach zu aktualisieren ist (App speichert Artefaktverwaltungssysteme, Open Source-Repositorys usw.). ) gibt es fast keinen Hype um den Begriff Continuous Deployment. Sie werden nur bereitgestellt. Es ist keine große Sache - es ist kein Schmerz, der besonderen Fokus erfordert.

Die Tatsache, dass Continuous Deployment nicht generell für alle interessant ist, ist auch ein Argument dafür, dass die Schule, die behauptet, dass "Delivery" und "Deployment" Synonyme sind, alles falsch verstanden hat. Weil Continuous Delivery für alle durchaus sinnvoll ist - selbst wenn Sie eingebettete Software in Geräte ausführen oder Open Source-Plugins für ein Framework freigeben.

Die Definition Ihrer Universität, dass Continuous Deployment ein natürlicher nächster Schritt von Continuous Delivery ist, setzt implizit voraus, dass jede Lieferung, die einer Qualitätssicherung unterzogen wird, sofort für die Endbenutzer verfügbar sein sollte, näher an der Definition, die mein Stamm verwendet, um den Begriff "Continuous Deployment" zu beschreiben Release ", was wiederum ein weiteres Konzept ist, das generisch nicht für alle sinnvoll ist.

Eine Veröffentlichung kann eine sehr strategische oder politische Angelegenheit sein, und es gibt keinen Grund anzunehmen, dass jeder dies die ganze Zeit tun möchte (es sei denn, er ist ein Online-Buchladen eines Streaming-Service-Unternehmens). Unternehmen, die nicht immer alles blind freigeben, können jedoch eine Reihe von Gründen haben, warum sie ohnehin Meister der Bereitstellung sein möchten, sodass auch sie eine kontinuierliche Bereitstellung durchführen . Nicht von der Freigabe für die Produktion, sondern von Freigabekandidaten für produktionsähnliche Umgebungen.

Wieder glaube ich, dass Ihre Universität es falsch verstanden hat. Sie verwechseln "Continuous Deployment" mit "Continuous Release".

Kontinuierliche Bereitstellung ist einfach die Disziplin, das Ergebnis eines Entwicklungsprozesses kontinuierlich in eine produktionsähnliche Umgebung zu verschieben, in der Funktionstests in vollem Umfang durchgeführt werden können.

Die Continuous Delivery Storyline

Auf dem Bild wird alles lebendig:

Der Prozess der kontinuierlichen Integration sind die ersten beiden Aktionen im Zustandsübergangsdiagramm. Dies startet - falls erfolgreich - die Continuous Delivery-Pipeline, die die Definition von done implementiert . Die Bereitstellung ist nur eine der vielen Aktionen, die in dieser Pipeline kontinuierlich ausgeführt werden müssen. Im Idealfall wird der Prozess von dem Punkt an, an dem sich der Entwickler zum VCS verpflichtet, bis zu dem Punkt automatisiert, an dem die Pipeline bestätigt hat, dass wir einen gültigen Release-Kandidaten haben.

Weder die Frage noch die Antworten passen wirklich zu meiner einfachen Denkweise. Ich bin Berater und habe diese Definitionen mit einer Reihe von Entwicklerteams und DevOps-Mitarbeitern synchronisiert. Ich bin jedoch gespannt, wie sie mit der Branche insgesamt übereinstimmen:

Grundsätzlich halte ich die agile Praxis der kontinuierlichen Bereitstellung für ein Kontinuum:

Nicht kontinuierlich (alles manuell) 0% ----> 100% Kontinuierliche Wertschöpfung (alles automatisiert)

Schritte zur kontinuierlichen Lieferung:

Null. Nichts wird automatisiert, wenn Entwickler Code einchecken ... Sie haben Glück, wenn sie vor dem Einchecken kompiliert, ausgeführt oder Tests durchgeführt haben.

1. Kontinuierliche Erstellung : Automatische Erstellung bei jedem Check-in. Dies ist der erste Schritt, beweist jedoch nicht die funktionale Integration von neuem Code.

2. Continuous Integration (CI): Automatisierte Erstellung und Ausführung von mindestens Komponententests zum Nachweis der Integration von neuem Code in vorhandenen Code, vorzugsweise jedoch Integrationstests (Ende-zu-Ende).

3. Continuous Deployment (CD): Automatisierte Bereitstellung, wenn Code CI mindestens in eine Testumgebung übergibt, vorzugsweise in höhere Umgebungen, wenn die Qualität entweder über CI nachgewiesen wird oder indem eine niedrigere Umgebung nach manuellen Tests als PASSED markiert wird. IE, das Testen kann in einigen Fällen manuell sein, aber das Heraufstufen in die nächste Umgebung erfolgt automatisch.

4. Kontinuierliche Lieferung: Automatisierte Veröffentlichung und Freigabe des Systems in der Produktion. Dies ist eine CD in der Produktion sowie alle anderen Konfigurationsänderungen wie die Einrichtung für A / B-Tests, die Benachrichtigung der Benutzer über neue Funktionen, die Benachrichtigung über die Unterstützung neuer Versionen und Änderungshinweise usw.

EDIT: Ich möchte darauf hinweisen, dass es einen Unterschied zwischen dem Konzept der "kontinuierlichen Lieferung" gibt, auf das im ersten Prinzip des Agilen Manifests ( http://agilemanifesto.org/principles.html ) Bezug genommen wird, und der Praxis der kontinuierlichen Lieferung. wie im Kontext der Frage zu verweisen scheint. Das Prinzip der kontinuierlichen Lieferung besteht darin, die Bestandsverschwendung zu reduzieren, wie in Lean Thinking ( http://www.miconleansixsigma.com/8-wastes.html ) beschrieben. Die Praxis der kontinuierlichen Bereitstellung (Continuous Delivery, CD) durch agile Teams hat sich in den vielen Jahren seit der Erstellung des agilen Manifests im Jahr 2001 herausgebildet. Diese agile Praxis befasst sich direkt mit dem Prinzip, obwohl es sich um verschiedene Dinge handelt, die anscheinend leicht zu verwechseln sind.

Ich denke, Amazon Definition ist klar und einfach zu verstehen.

" Continuous Delivery ist eine Softwareentwicklungsmethode, bei der der Freigabeprozess automatisiert wird. Jede Softwareänderung wird automatisch erstellt, getestet und für die Produktion bereitgestellt. Vor dem endgültigen Push in die Produktion entscheidet eine Person, ein automatisierter Test oder eine Geschäftsregel, wann die Der endgültige Push sollte erfolgen. Obwohl jede erfolgreiche Softwareänderung bei kontinuierlicher Lieferung sofort für die Produktion freigegeben werden kann, müssen nicht alle Änderungen sofort freigegeben werden.

Kontinuierliche Integration ist eine Softwareentwicklungspraxis, bei der Mitglieder eines Teams ein Versionskontrollsystem verwenden und ihre Arbeit häufig an demselben Ort integrieren, z. B. in einer Hauptniederlassung. Jede Änderung wird durch Tests und andere Überprüfungen erstellt und überprüft, um Integrationsfehler so schnell wie möglich zu erkennen. Die kontinuierliche Integration konzentriert sich auf das automatische Erstellen und Testen von Code im Vergleich zur kontinuierlichen Bereitstellung, die den gesamten Software-Release-Prozess bis zur Produktion automatisiert . "

Bitte überprüfen Sie http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Atlassian hat eine gute Erklärung zu Continuous Integration vs. Continuous Delivery vs. Continuous Deployment veröffentlicht .

In einer Nussschale:

Kontinuierliche Integration - ist eine Automatisierung zum Erstellen und Testen von Anwendungen, wenn neue Commits in den Zweig verschoben werden.

Kontinuierliche Lieferung - ist kontinuierliche Integration + Bereitstellung der Anwendung für die Produktion durch "Klicken auf eine Schaltfläche" (Freigabe an Kunden erfolgt häufig, jedoch auf Anfrage).

Continuous Deployment - ist kontinuierliche Lieferung aber ohne menschliches Zutun (Release an Kunden ist im Gange).

Kontinuierliche Integration bedeutet im Grunde nur, dass die Arbeitskopien des Entwicklers mehrmals täglich mit einer gemeinsam genutzten Hauptleitung synchronisiert werden.

Oder mehr als mehrmals am Tag. Grundsätzlich so oft, wie eine bestimmte diskrete Aufgabe erledigt ist. Stellen Sie sich zum Beispiel ein Entwicklerteam vor, das an einer einzelnen Geschäftsanwendung arbeitet. In vielen Umgebungen kann Folgendes passieren:

• Ein oder zwei Entwickler behalten lokale Änderungen für einige Tage bei, weil "es noch nicht fertig ist".
• Ein oder zwei Entwickler erstellen Zweige in der Quellcodeverwaltung, damit sie an ihren Funktionen arbeiten können, "ohne von den Änderungen anderer Personen gestört zu werden".

Dies kann zu Problemen führen. Eine schlechte Code- / Aufgabenorganisation führt zu Verzweigungen, Verzweigungen führen zu Verschmelzungen, Verschmelzungen ... führen zu Leiden. Die kontinuierliche Integration als Praxis spricht dies an, indem alle dazu ermutigt werden, aus derselben gemeinsamen Quelle zu arbeiten. Einzelne Arbeitselemente sollten diskret genug sein, um in kurzer Zeit (höchstens Stunden) erledigt zu werden.

Grundsätzlich besteht die allgemeine Idee darin, eine kleine Änderung in einen kleinen Arbeitsaufwand zu integrieren. Die Integration einer großen Veränderung ist ein unverhältnismäßig großer Arbeitsaufwand. Die Gesamtheit der Integrationsarbeit ist kleiner, wenn sie in konstanten kleinen Schritten ausgeführt wird. Auf diese Weise können Entwickler mehr Zeit für geschäftlich sichtbare Funktionen aufwenden als für den Entwicklungsprozess.

Continuous Delivery wird als logische Weiterentwicklung der kontinuierlichen Integration beschrieben: Immer in der Lage sein, ein Produkt in Produktion zu bringen!

Dies folgt der gleichen Idee von diskreten, genau definierten Arbeitselementen. Wenn es eine einzelne Master-Codebasis gibt, die immer nur in kleinen Schritten durch vollständige, getestete und bekannte Arbeitsfunktionen angepasst wird, ist diese Codebasis immer stabil. Automatisierte Tests sind hier entscheidend, um diese Stabilität auf Knopfdruck nachweisen zu können.

Je weniger Stabilisierungsarbeiten durchgeführt werden müssen (was wiederum den Entwicklungsprozessaufwand verursacht und beseitigt werden sollte), desto häufiger kann die Codebasis auf eine bestimmte Umgebung übertragen werden. In vielen Unternehmen kann eine Bereitstellung ein ziemlich anstrengender Prozess sein. Sogar ein einwöchiger All-Hands-on-Deck-Betrieb. Dies ist teuer und erzeugt keinen Geschäftswert. Durch die Verwendung guter Workitem-Definitionen, effektiver automatisierter Tests und kontinuierlicher Integration kann ein Team in der Lage sein, die Bereitstellung der Codebasis für eine bestimmte Umgebung zu automatisieren.

Die kontinuierliche Bereitstellung wird als logischer nächster Schritt nach der kontinuierlichen Bereitstellung beschrieben: Stellen Sie das Produkt automatisch in der Produktion bereit, wenn es die Qualitätssicherung besteht!

Sie werden dies selten in einem Geschäftsumfeld sehen, und es ist eine große Freude, wenn es angetroffen wird. Wenn die Codebasis automatisch getestet und automatisch in einer bestimmten Umgebung bereitgestellt werden kann, ist die Produktion eine Umgebung wie jede andere. Wenn sich das Team bis zu diesem Zeitpunkt aufgebaut hat, besteht für diesen ein Potenzial für einen erheblichen Mehrwert, da immer Updates für die Produktion bereitgestellt werden können.

Fehlerbehebungen werden schneller an Kunden gesendet, neue Funktionen erreichen den Markt schneller, neue Ideen werden in kleineren Schritten gegen den Markt getestet, um eine Neuausrichtung der Prioritäten usw. zu ermöglichen.

Nehmen wir zum Beispiel an, ein Unternehmen hat eine große Idee für eine neue Funktion in seinem softwarebasierten Produkt oder seiner Dienstleistung. Sie haben einige Nachforschungen angestellt, kennen den Markt und glauben, dass diese Idee zu einer starken neuen Umsatzlinie führen wird. Betrachten Sie nun zwei Optionen für die Bereitstellung dieser Funktion:

1. Verbringen Sie Monate damit, das Ganze in einer einmaligen Filiale zu entwickeln. Verbringen Sie Wochen damit, es wieder in die Hauptcodebasis zu integrieren. Verbringen Sie Tage damit, es zu testen. Verbringen Sie einen Tag damit, es bereitzustellen. Und erst dann verfolgen Sie die tatsächlichen Einnahmen im Produktionssystem.
2. Implementieren Sie nacheinander kleine Teile der Funktion. Jede Woche ein neues Stück davon veröffentlichen. Jede Woche erhalten Sie mehr Daten über die tatsächlichen Einnahmen.

Wenn die Funktion im ersten Szenario nicht den gewünschten Markteffekt hat, wird viel Geld für etwas verschwendet, das Kunden eigentlich nicht wollen. Im zweiten Szenario wird die Tatsache, dass Kunden es nicht wollen, viel früher festgestellt und der Rest der Arbeit wird de-priorisiert.

Letztendlich geht es bei diesen "kontinuierlichen Dingen" darum, den Entwicklungsprozess-Overhead zu beseitigen. Wenn es sich bei der Umsatzlinie eines Unternehmens um ein bestimmtes Serviceangebot handelt, sollten im Idealfall alle Kosten in dieses Angebot fließen. Der Aufwand für den Entwicklungsprozess (Zusammenführen von Code, erneutes Testen derselben Funktionen nach dem Zusammenführen, manuelle Bereitstellungsaufgaben usw.) trägt nicht zum Wert des Dienstes bei. Daher versuchen diese Konzepte, diese Kosten aus dem Prozess zu entfernen.

Ein Diagramm kann viele Wörter ersetzen:

Genießen! :-)

# Ich habe das richtige Bild aktualisiert ...

Unterschied zwischen kontinuierlicher Integration, kontinuierlicher Bereitstellung und kontinuierlicher Bereitstellung

Ich denke, wir sind damit fertig, die "kontinuierliche" Wortreihe zu analysieren und vielleicht ein bisschen zu komplizieren. Kontinuierlich bedeutet in diesem Zusammenhang Automatisierung. Verwenden Sie für die anderen Wörter, die an "kontinuierlich" angehängt sind, die englische Sprache als Übersetzungsanleitung und versuchen Sie bitte nicht, die Dinge zu komplizieren! In "Continuous Build" bauen wir unsere Anwendung automatisch in etwas ein (schreiben / kompilieren / verknüpfen / usw.), das für eine bestimmte Plattform / einen bestimmten Container / eine bestimmte Laufzeit / usw. Ausführbar ist. "Kontinuierliche Integration" bedeutet, dass Ihre neue Funktionalität bei der Interaktion mit einer anderen Entität getestet und wie beabsichtigt ausgeführt wird. Bevor die Integration stattfindet, muss der Build natürlich stattfinden, und es werden auch gründliche Tests verwendet, um die Integration zu validieren. Also, in "kontinuierlicher Integration" Man nutzt die Automatisierung, um einem vorhandenen Funktionsumfang einen Mehrwert zu verleihen, der die vorhandene Funktionalität nicht negativ stört, sondern sich gut in sie integriert und dem Ganzen einen wahrgenommenen Wert hinzufügt. Integration impliziert durch seine bloße englische Definition, dass die Dinge harmonisch zusammenleben, so dass ich im Code-Talk meine Add-Kompilierungen, Links, Tests und Läufe perfekt innerhalb des Ganzen mache. Sie würden nicht etwas Integriertes nennen, wenn das Endprodukt versagen würde, oder?! In unserem Kontext ist "Kontinuierliche Bereitstellung" gleichbedeutend mit "Kontinuierliche Bereitstellung", da wir unseren Kunden letztendlich Funktionen zur Verfügung gestellt haben. Wenn ich dies jedoch übermäßig analysiere, könnte ich argumentieren, dass die Bereitstellung eine Teilmenge der Bereitstellung ist, da die Bereitstellung von etwas nicht unbedingt bedeutet, dass wir geliefert haben. Wir haben den Code bereitgestellt, aber weil wir ' Um unseren Stakeholdern nicht effektiv zu kommunizieren, konnten wir aus geschäftlicher Sicht keine Ergebnisse erzielen! Wir haben die Truppen eingesetzt, aber das versprochene Wasser und Essen nicht in die nahe gelegene Stadt geliefert. Was wäre, wenn ich den Begriff "kontinuierlicher Übergang" hinzufügen würde, hätte er seinen eigenen Wert? Schließlich ist es vielleicht besser geeignet, die Bewegung von Code durch Umgebungen zu beschreiben, da es mehr die Konnotation "von / nach" hat als die Bereitstellung oder Bereitstellung, die auf Dauer nur einen Ort implizieren könnte! Das bekommen wir, wenn wir keinen gesunden Menschenverstand anwenden. hätte es seinen eigenen Verdienst? Schließlich ist es vielleicht besser geeignet, die Bewegung von Code durch Umgebungen zu beschreiben, da es mehr die Konnotation "von / nach" hat als die Bereitstellung oder Bereitstellung, die auf Dauer nur einen Ort implizieren könnte! Das bekommen wir, wenn wir keinen gesunden Menschenverstand anwenden. hätte es seinen eigenen Verdienst? Schließlich ist es vielleicht besser geeignet, die Bewegung von Code durch Umgebungen zu beschreiben, da es mehr die Konnotation "von / nach" hat als die Bereitstellung oder Bereitstellung, die auf Dauer nur einen Ort implizieren könnte! Das bekommen wir, wenn wir keinen gesunden Menschenverstand anwenden.

Zusammenfassend lässt sich sagen, dass dies einfach zu beschreiben ist (es ist etwas komplizierter!). Verwenden Sie einfach den gesunden Menschenverstand und die englische Sprache, und es wird Ihnen gut gehen.

Kontinuierliche Integration: Die Praxis, die Entwicklungsarbeit ständig mit dem Hauptzweig zusammenzuführen, damit der Code so oft wie möglich getestet wird, um Probleme frühzeitig zu erkennen.

Kontinuierliche Lieferung: Kontinuierliche Lieferung von Code an eine Umgebung, sobald der Code versandbereit ist. Dies kann Inszenierung oder Produktion sein. Die Idee ist, dass das Produkt an eine Benutzerbasis geliefert wird, bei der es sich um Qualitätssicherungen oder Kunden zur Überprüfung und Inspektion handeln kann.

Der Komponententest während der Phase der kontinuierlichen Integration kann nicht alle Fehler und Geschäftslogiken erfassen, insbesondere Designprobleme. Aus diesem Grund benötigen wir zum Testen eine Qualitätssicherung oder eine Staging-Umgebung.

Kontinuierliche Bereitstellung: Die Bereitstellung oder Freigabe von Code, sobald dieser bereit ist. Kontinuierliche Bereitstellung erfordert kontinuierliche Integration und kontinuierliche Bereitstellung, da sonst die Codequalität in einer Version nicht garantiert wird.

Kontinuierliche Bereitstellung ~~ Kontinuierliche Integration + Kontinuierliche Bereitstellung

Kontinuierliche Integration

• Automatisiert (Aufbau von Check-Ins + Unit-Test)

Kontinuierliche Lieferung

• Kontinuierliche Integration
• Automatisiert (Bereitstellung in Testumgebung + Lasttest + Integrationstest)
• Handbuch (Bereitstellung in der Produktion)

Kontinuierliche Bereitstellung

• Kontinuierliche Lieferung, jedoch automatisiert (Bereitstellung in der Produktion)

CI / CD ist eine Reise. Kein Ziel.

Diese Phasen sind Vorschläge. Sie können die Phasen an Ihre geschäftlichen Anforderungen anpassen. Einige Phasen können für verschiedene Arten von Tests, Sicherheit und Leistung wiederholt werden. Abhängig von der Komplexität Ihres Projekts und der Struktur Ihrer Teams können einige Phasen auf verschiedenen Ebenen mehrmals wiederholt werden. Beispielsweise kann das Endprodukt eines Teams zu einer Abhängigkeit im Projekt des nächsten Teams werden. Dies bedeutet, dass das Endprodukt des ersten Teams anschließend als Artefakt im Projekt des nächsten Teams bereitgestellt wird.

Fußnote:

Kontinuierliche Integration und kontinuierliche Bereitstellung in AWS üben

Quelle: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

Was ist kontinuierliche Integration? Kontinuierliche Integration ist ein Prozess oder eine Entwicklungspraxis für automatisierte Erstellung und automatisierten Test. Das heißt, ein Entwickler muss seinen Code mehrmals in ein gemeinsam genutztes Repository übertragen, in dem jede Integration durch automatisierte Erstellung und Prüfung überprüft wird.

Wenn der Build fehlschlägt / erfolgreich ist, wird er einem Entwickler mitgeteilt und er kann relevante Maßnahmen ergreifen.

Was ist Continuous Delivery? Continuous Delivery ist die Praxis, bei der wir unseren Code zu jedem Zeitpunkt bereitstellbar halten, der den gesamten Test bestanden hat und über die erforderliche Konfiguration verfügt, um den Code in die Produktion zu übertragen, aber noch nicht bereitgestellt wurde.

Was ist kontinuierliche Bereitstellung? Mit Hilfe von CI haben wir einen Build für unsere Anwendung erstellt und sind bereit, die Produktion voranzutreiben. In diesem Schritt ist unser Build fertig und mit CD können wir unsere Anwendung direkt in der QS-Umgebung bereitstellen. Wenn alles gut läuft, können wir denselben Build für die Produktion bereitstellen.

Die kontinuierliche Bereitstellung ist also im Grunde einen Schritt weiter als die kontinuierliche Bereitstellung. Mit dieser Vorgehensweise wird jede Änderung, die alle Phasen Ihrer Produktionspipeline durchläuft, für Ihre Kunden freigegeben.

Continuous Deployment ist eine Kombination aus Konfigurationsmanagement und Containerisierung.

Konfigurationsmanagement: Bei CM geht es darum, die Konfiguration des Servers beizubehalten, die mit den Anwendungsanforderungen kompatibel ist.

Containerisierung : Containerisierung ist eine Reihe von Mautgebühren, die die Konsistenz in der gesamten Umwelt gewährleisten.

Bildquelle: https://www.atlassian.com/

DevOps ist eine Kombination aus 3Cs - kontinuierlich , Kommunikation , Zusammenarbeit und dies führt zu einem Schwerpunkt in verschiedenen Branchen.

In einer Welt mit IoT-verbundenen Geräten arbeiten mehrere Scrum-Funktionen wie Product Owner, Web, Mobile und QA agil in einem Scrum-of-Scrum-Zyklus, um ein Produkt an den Endkunden zu liefern.

Kontinuierliche Integration: Mehrere Scrum-Funktionen arbeiten gleichzeitig an mehreren Endpunkten

Kontinuierliche Lieferung: Durch Integration und Bereitstellung kann die Lieferung des Produkts an mehrere Kunden gleichzeitig abgewickelt werden.

Kontinuierliche Bereitstellung: Mehrere Produkte werden für mehrere Kunden auf mehreren Plattformen bereitgestellt.

Sehen Sie sich dies an, um zu erfahren, wie DevOps die IoT-verbundene Welt aktiviert: https://youtu.be/nAfZt2t4HqA

Nach dem, was ich mit Alex Cowan im Kurs Continuous Delivery & DevOps gelernt habe , sind CI und CD Teil einer Produktpipeline, die aus der Zeit besteht, die von einer Beobachtung zu einem freigegebenen Produkt reicht.

Von Beobachtungen bis zu Designs ist es das Ziel, qualitativ hochwertige testbare Ideen zu erhalten. Dieser Teil des Prozesses wird als kontinuierliches Design betrachtet .

Was danach passiert, wenn wir vom Code an fortfahren, wird dies als kontinuierliche Lieferfunktion angesehen , deren Ziel es ist, die Ideen umzusetzen und dem Kunden sehr schnell zur Verfügung zu stellen (Sie können Jez Humbles Buch Kontinuierliche Lieferung: Zuverlässige Softwareversionen durch Erstellen, Testen, lesen). und Deployment Automation für weitere Details). In der folgenden Pipeline wird erläutert, aus welchen Schritten Continuous Integration (CI) und Continuous Delivery (CD) bestehen.

Kontinuierliche Integration , wie Mattias Petter Johansson erklärt ,

Dies ist der Fall, wenn ein Softwareteam die Gewohnheit hat, mehrere Zusammenführungen pro Tag durchzuführen, und über ein automatisiertes Überprüfungssystem verfügt, um diese Zusammenführungen auf Probleme zu überprüfen.

(Mit CircleCI können Sie die folgenden beiden Videos ansehen, um einen praktischen Überblick zu erhalten. Erste Schritte mit CircleCI - Kontinuierliche Integration P2 und Ausführen von CircleCI auf Pull-Anforderung ).

Man kann die CI / CD-Pipeline wie folgt angeben, die vom neuen Code zu einem freigegebenen Produkt führt.

Die ersten drei Schritte haben mit Tests zu tun und erweitern die Grenzen des zu testenden Objekts.

Bei der kontinuierlichen Bereitstellung wird die Bereitstellung hingegen automatisch ausgeführt. Daher wird jedes Code-Commit, das die automatisierte Testphase besteht, automatisch in die Produktion freigegeben.

Hinweis : So müssen Ihre Pipelines nicht unbedingt aussehen, sie können jedoch als Referenz dienen.

Lassen Sie es uns kurz halten:

CI: Eine Softwareentwicklungspraxis, bei der Mitglieder eines Teams ihre Arbeit mindestens täglich integrieren. Jede Integration wird durch automatisierte Erstellung (einschließlich Tests) überprüft, um Fehler so schnell wie möglich zu erkennen. CD: CD Baut auf CI auf, wo Sie Software so erstellen, dass die Software jederzeit für die Produktion freigegeben werden kann.