Was ist der Unterschied zwischen Pipeline und Release Pipeline in Azure Devops?

Eine Yaml-Datei wird generiert, während Sie diese unten gezeigte Option auswählen:

In dieser yaml-Datei können Sie einen gesamten Bereitstellungszyklus ab definieren restore -> build -> run tests -> publish and -> deploy to azure app service web app.

Warum gibt es dann die Release-Option? Wenn ich über die Pipelines -> PipelinesOption einen gesamten Lebenszyklus definieren kann , welchen Zweck hat die Pipelines -> ReleasesOption?

Pipelines ist ein Name in der neuesten DevOps-Benutzeroberfläche für Builds. In der alten Benutzeroberfläche ist es so:

Es kann gesagt werden, dass Pipeline(oder Build oder Build Pipeline) CI (kontinuierliche Integration) in Azure DevOps darstellt. Releasesteht für CD (Continuous Delivery) in Azure DevOps. Pipeline nimmt normalerweise Code, erstellt ihn, testet und erstellt ein Artefakt. Release nimmt das Artefakt und gibt es frei.

Die Verwendung hängt von Ihrem Projekt ab.

Wenn Sie ein kleines Projekt haben und keine Release-Funktionen erforderlich sind (z. B. Bedingungen und Genehmigungen vor der Bereitstellung), können Sie Pipeline wie erwähnt verwenden: restore -> build -> tests -> deployund keine Notwendigkeit in Release.

Wenn Ihr Projekt groß ist und viele Entwicklerbeiträge leisten, ist es gut, eine Pipeline zu haben, die jedes Mal erstellt, Unit-Tests durchführt, andere Automatisierungen und Ergebnisse mit Artefakten durchführt, wenn Entwickler auf das gemeinsame Repo drängen. So können Sie sicher sein, dass alles erledigt ist und die Integrationstests bestanden wurden. Pipeline kann auch dazu führen, dass Aufgaben für interne Arbeit, Verwendung und Tests für Entwicklungsumgebungen / Server freigegeben / bereitgestellt werden.

In großen Projekten müssen Sie nicht jeden Push für das gemeinsame Repo bereitstellen. So können Sie ein Release festlegen, das für die Bereitstellung in der Produktionsumgebung verantwortlich ist. Es verfügt über Funktionen, die dafür entwickelt wurden, wie z. B. die Vorabgenehmigung, sodass sich alle einig sind, dass es sich um den richtigen Build (oder das richtige Artefakt) für die Produktion handelt.

Wie in Microsoft-Dokumenten erwähnt, ist der Abschnitt "Releases" die Lösung für den "klassischen Editor": Link

Der Abschnitt "Pipelines" bietet die Möglichkeit, Pipelines auf zwei Arten zu erstellen:

1. YAML-Code
2. Klassischer UI-Editor

Was Classic im Grunde bedeutet, ist die ursprüngliche Art und Weise, wie Azure DevOps-Pipelines erstellt werden. Sie erstellen eine Pipeline mithilfe eines GUI-Editors auf interaktive Weise. Die aus YAML mit Hilfe des Assistenten erstellte Pipeline ist der neuere Weg .

Der Abschnitt "Pipelines" hat hauptsächlich das, was "Releases" nicht bedeutet, dass Sie durch Schreiben von YAML-Code Ihre CI / CD-Strategie als Code konfigurieren können, wobei die Pipeline-Definition neben und zusammen mit Ihrem Code lebt.

Die neuesten Lernressourcen geben außerdem an, YAML zu verwenden und Build- und Bereitstellungsphasen in derselben Pipeline zu erstellen. Stellen Sie Anwendungen mit Azure DevOps bereit

Ich empfehle:

• Wenn Sie den klassischen UI- Editor bevorzugen, verwenden Sie den Abschnitt "Pipelines" für Builds und den Abschnitt "Release" für Bereitstellungen.
• Wenn Sie YAML bevorzugen, verwenden Sie einfach den Abschnitt "Pipelines" für Builds und Bereitstellungen und erstellen Sie eine mehrstufige Pipeline.

Pipeline mit mehreren Stufen