CI/CD-Pipelines ci-cd-pipeline

Erfahren Sie mehr über CI/CD-Pipelines und wie sie Bereitstellungen in Staging- und Produktionsumgebungen in Cloud Manager handhaben.

Überblick overview

Cloud Manager enthält ein Continuous Integration/Continuous Delivery (CI/CD) Framework, mit dem Implementierungs-Teams schnell neuen oder aktualisierten Code testen und bereitstellen können. Implementierungs-Teams können eine automatisierte CI/CD-Pipeline einrichten, konfigurieren und starten. Diese Pipeline folgt den Adobe Best Practices beim Programmieren, um einen umfassenden Codescan durchzuführen und höchste Code-Qualität sicherzustellen.

Die CI/CD-Pipeline automatisiert außerdem die Unit- und Leistungstests, um die Bereitstellungseffizienz zu erhöhen und proaktiv wichtige Probleme zu erkennen, deren Behebung nach der Bereitstellung hohe Kosten verursacht. Implementierungs-Teams können auf einen umfassenden Code-Leistungsbericht zugreifen, um einen Überblick über die potenziellen Auswirkungen auf KPIs und kritische Sicherheitsprüfungen für den Fall zu erhalten, dass der Code in der Produktion bereitgestellt wird.

Über den Pipeline-Prozess pipeline-process

Das folgende Diagramm zeigt, was passiert, wenn eine Release-Veröffentlichung unter Verwendung einer Pipeline in Cloud Manager ausgelöst wird.

Der Pipeline-Prozess

Pipeline-Schritt
Beschreibung
​1. Starten einer Version
Ein Bereitstellungs-Manager löst die Release-Veröffentlichung entweder manuell (per Git-Commit) oder basierend auf einem wiederkehrenden Zeitplan aus.
​2. Erstellen eines Release-Tags
Cloud Manager erstellt ein Git-Tag, um die Release-Version mit einer automatisch generierten Versionsnummer zu kennzeichnen, z. B. 2018.531.245527.0000001222.
​3. Als Version mit automatisch generierter Version erstellt
Cloud Manager erstellt die Anwendung mit der neu zugewiesenen Versionsnummer.
​4. Bewertung der Code-Qualität
Cloud Manager scannt den Quell-Code und stellt eine Zusammenfassung bereit, bevor der Code in der Staging-Umgebung bereitgestellt werden kann.
​5. Gespeicherte versionierte Artefakte
Die Release-Artefakte werden zur späteren Verwendung in den Bereitstellungsschritten gespeichert.
​6. Automatische Bereitstellung von Artefakten für AMS AEM-Staging
Das Release-Artefakt wird in der Staging-Umgebung bereitgestellt.
​7. Automatisierte Trigger-Tests
Cloud Manager führt die Leistungs- und Sicherheitstests für das Artefakt aus.
​8. Bereitstellung von Produktions-Trigger
Sobald die automatisierten Tests abgeschlossen sind, startet Cloud Manager die Bereitstellung in der Produktionsumgebung.
​9. Cloud Manager ruft Artefakte zur Bereitstellung ab
Cloud Manager ruft die gespeicherten Release-Artefakte ab.
​10. Bereitstellen von Artefakten für die Produktion
Die Release-Artefakte werden in der Produktionsumgebung bereitgestellt.

Code-Quellen code-sources

Pipelines können sich zusätzlich zu Produktions- und Nicht-Produktions-Pipelines auch nach dem Typ des bereitgestellten Codes unterscheiden.

Full-Stack-Pipelines full-stack-pipeline

Full-Stack-Pipelines stellen den vollständigen AEM-Anwendungs-Code für die AEM-Laufzeit bereit und stellen standardmäßig auch Web-Stufen-Konfigurationen bereit.

Folgende Einschränkungen gelten.

  • Ein Benutzer muss mit der Rolle „Bereitstellungs Manager“ angemeldet sein um Pipelines konfigurieren oder ausführen zu können.
  • Es kann immer nur eine Full-Stack-Pipeline pro Umgebung geben.

Im Folgenden wird beschrieben, wie die Full-Stack-Pipeline mit einer Web-Stufen-Konfigurations-Pipeline interagiert.

  • Die Full-Stack-Pipeline für eine Umgebung ignoriert die Dispatcher-Konfiguration, wenn die entsprechende Web-Stufen-Konfigurations-Pipeline vorhanden ist.
  • Wenn die entsprechende Web-Stufen-Konfigurations-Pipeline für die Umgebung nicht vorhanden ist, kann die Benutzerin bzw. der Benutzer die Full-Stack-Pipeline so konfigurieren, dass sie die Dispatcher-Konfiguration berücksichtigt oder ignoriert.

Full-Stack-Pipelines können Pipelines zur Code-Qualitätsprüfung oder für die Bereitstellung sein.

Konfigurieren von Full-Stack-Pipelines configure-full-stack

Siehe Hinzufügen einer Produktions-Pipeline.
Siehe Hinzufügen einer produktionsfremden Pipeline.

Web-Stufen-Konfigurations-Pipelines web-tier-config-pipelines

Web-Stufen-Konfigurations-Pipelines ermöglichen die exklusive Bereitstellung der HTTPD-/Dispatcher-Konfiguration zur AEM-Runtime, indem sie sie von anderen Code-Änderungen entkoppeln. Es handelt sich um eine optimierte Pipeline, die Benutzenden, die nur Änderungen an der Dispatcher-Konfiguration bereitstellen möchten, eine beschleunigte Möglichkeit bietet, dies innerhalb weniger Minuten zu tun.

TIP
Mit Web-Stufen-Konfigurations-Pipelines können Sie Ihre Web-Konfiguration an demselben oder einem anderen Quellspeicherort wie die Full-Stack-Pipeline speichern, je nachdem, was für Ihre Projektstruktur am besten ist.

Folgende Einschränkungen gelten.

  • Ein Benutzer muss mit der Rolle „Bereitstellungs Manager“ angemeldet sein um Pipelines konfigurieren oder ausführen zu können.
  • Es kann immer nur eine Web-Ebenen-Konfigurations-Pipeline pro Umgebung geben.
  • Benutzende können eine Web-Ebenen-Konfigurations-Pipeline nicht konfigurieren, wenn die entsprechende Full-Stack-Pipeline ausgeführt wird.

Im folgenden Beispiel wird beschrieben, wie die Web-Stufen-Konfigurations-Pipeline mit der Full-Stack-Pipeline interagiert.

  • Wenn für eine Umgebung keine Web-Stufen-Konfigurations-Pipeline eingerichtet ist, kann die Benutzerin oder der Benutzer beim Konfigurieren der Full-Stack-Pipeline wählen, ob die Dispatcher-Konfiguration einbezogen oder ignoriert werden soll.
  • Sobald eine Web-Stufen-Konfigurations-Pipeline für eine Umgebung konfiguriert wurde, ignoriert die entsprechende Full-Stack-Pipeline (sofern vorhanden) die Dispatcher-Konfiguration während der Ausführung und Bereitstellung.
  • Nachdem eine Web-Stufen-Konfigurations-Pipeline gelöscht wurde, wird die zugehörige Full-Stack-Pipeline (sofern vorhanden) zurückgesetzt, um während der Ausführung Dispatcher-Konfigurationen bereitzustellen.
NOTE
Bei AMS-Programmen mit aktivierter Blau/Grün-Bereitstellung verwenden Web-Stufen-Updates standardmäßig eine rollierende Bereitstellung. Verwenden Sie eine Full-Stack-Pipeline, wenn Sie eine Blau/Grün-Bereitstellung für Web-Stufen-Änderungen benötigen.

Konfigurieren von Web-Stufen-Pipelines configure-web-tier

Siehe Hinzufügen einer Produktions-Pipeline.
Siehe Hinzufügen einer produktionsfremden Pipeline.

Schnellere Builds mit Smart Build use=smart-build

Cloud Manager verwendet jetzt eine optimierte Build-Strategie namens Smart Build, die Caching auf Modulebene verwendet, um den Build-Prozess zu beschleunigen. Bei jedem Build werden nur geänderte Module neu erstellt, während unveränderte Module aus dem Cache wiederverwendet werden.

Smarter Build ist nur für Code-Qualitäts- und Entwicklungs-Full-Stack-Bereitstellungs-Pipelines verfügbar.

Siehe Hinzufügen einer produktionsfremden Pipeline und Informationen zur Verwendung von Smart Build in einer produktionsfremden Pipeline.

Einrichten einer CI/CD-Pipeline how-to-setup-a-ci-cd-pipeline

Weitere Informationen zur Pipeline-Konfiguration finden Sie unter Konfigurieren von Produktions-Pipelines und Konfigurieren produktionsfremder Pipelines.

Quality Gates quality-gates

Die CI/CD-Pipeline bietet Quality Gates (bzw. Akzeptanzkriterien), die erfüllt werden müssen, bevor der Code aus der Staging-Umgebung in die Bereitstellungsumgebung verschoben werden kann. Die Pipeline muss drei Akzeptanztests bestehen:

  • Code-Qualität
  • Leistungstests
  • Sicherheitstests

Für jeden dieser Akzeptanztests sind drei Stufen von Problemen definiert:

  • Kritisch: Beim Test festgestellte ausschlaggebende Probleme, die ein sofortiges Fehlschlagen der Pipeline verursachen.
  • Wichtig: Beim Test festgestellte wichtige Probleme, durch die die Pipeline angehalten wird. Bereitstellungs-Managerinnen bzw. -Manager, Projekt-Managerinnen bzw. -Manager oder Geschäftsinhaberinnen bzw. -inhaber können die Probleme übergehen, sodass die Pipeline fortgesetzt werden kann. Alternativ können sie die Probleme akzeptieren, wodurch die Pipeline mit einem Fehler angehalten wird.
  • Information: Beim Test festgestellte Probleme informativer Natur, die ausschließlich zu Informationszwecken genannt werden und keine Auswirkungen auf die Pipeline-Ausführung haben.

Dies ist ein Beispiel für einen Codescan mit festgestellten Problemen:

Beispiel für Code-Prüfung

Einrichten von Gates how-to-setup-gates

Weitere Informationen zum Einrichten von Code-, Qualitäts- und Leistungs-Akzeptanztests finden Sie unter Konfigurieren von Produktions-Pipelines.

recommendation-more-help
experience-manager-cloud-manager-help-main-toc