Code-Bereitstellung

Erfahren Sie, wie Sie Code bereitstellen und was dabei in Cloud Manager passiert.

Bereitstellen von Code mit Cloud Manager

Sobald die Produktions-Pipeline einschließlich des erforderlichen Repositorys und der erforderlichen Umgebungen konfiguriert ist, kann der Code bereitgestellt werden.

1. Klicken Sie in Cloud Manager auf Bereitstellen, um den Bereitstellungsprozess zu starten.

   

2. Der Bildschirm Pipeline-Ausführung wird angezeigt. Klicken Sie auf Build, um den Prozess zu starten.

   

Der Build-Prozess startet den Code-Bereitstellungsprozess einschließlich der folgenden Schritte:

• Staging-Bereitstellung
• Staging-Tests
• Produktionsbereitstellung

Sie können die Schritte verschiedener Bereitstellungsprozesse überprüfen, indem Sie die Protokolle lesen oder die Ergebnisse anhand der Testkriterien durchgehen.

Bereitstellungsschritte

In jedem Schritt der Bereitstellung werden verschiedene Aktionen ausgeführt, die in diesem Abschnitt beschrieben werden. Im Abschnitt Details zum Bereitstellungsprozess finden Sie technische Details dazu, wie der Code selbst hinter den Kulissen bereitgestellt wird.

Staging-Bereitstellung

Der Schritt Staging-Bereitstellung umfasst die folgenden Aktionen:

• Validierung: Dieser Schritt stellt sicher, dass die Pipeline so konfiguriert ist, dass die derzeit verfügbaren Ressourcen verwendet werden. So wird z. B. überprüft, ob die konfigurierte Verzweigung vorhanden ist und die Umgebungen verfügbar sind.
• Build- und Unit-Tests: Dieser Schritt führt einen containerisierten Build-Prozess aus. Einzelheiten finden Sie im Dokument Die Build-Umgebung.
• Codescan: Dieser Schritt bewertet die Qualität des Programm-Codes. Einzelheiten zum Testverfahren finden Sie im Dokument Grundlegendes zu Testergebnissen.
• Staging-Bereitstellung

Staging-Tests

Der Schritt Staging-Tests umfasst die folgenden Aktionen:

• Sicherheitstests: Dieser Schritt bewertet die Auswirkungen des Programm-Codes auf die Sicherheit der AEM-Umgebung. Einzelheiten zum Testverfahren finden Sie im Dokument Grundlegendes zu Testergebnissen.

  • Leistungstests: Dieser Schritt bewertet die Leistung des Codes. Einzelheiten zum Testverfahren finden Sie in unter Grundlegendes zu Testergebnissen.

  

Schritt zur Produktionsbereitstellung

Der Schritt Produktionsbereitstellung umfasst die folgenden Aktionen:

• Genehmigungsantrag
  • Diese Option ist beim Konfigurieren der Pipeline aktiviert.
  • Mit dieser Option können Sie die Produktionsbereitstellung planen. Oder klicken Sie auf Jetzt, um die Produktionsbereitstellung sofort auszuführen.
• Planen der Bereitstellung für die Produktion
  • Diese Option ist beim Konfigurieren der Pipeline aktiviert.
  • Datum und Uhrzeit für den Zeitplan beziehen sich auf die Zeitzone des Benutzers.
    
• CSE-Unterstützung (sofern aktiviert)
• Bereitstellung für Produktion

Sobald die Bereitstellung abgeschlossen ist, befindet sich der Code in der Zielumgebung und Sie können die Protokolle anzeigen.

Zeitüberschreitungen

Die folgenden Schritte führen zu einer Zeitüberschreitung, wenn auf Benutzer-Feedback gewartet wird:

Details zum Bereitstellungsprozess

Cloud Manager lädt alle beim Build-Prozess generierten target/*.zip-Dateien in einen Speicherort hoch. Diese Artefakte werden in der Pipeline-Bereitstellungsphase von diesem Speicherort abgerufen.

Wenn Cloud Manager in produktionsfremden Topologien bereitgestellt wird, besteht das Ziel darin, die Bereitstellung so schnell wie möglich abzuschließen. Daher werden die Artefakte wie folgt auf allen Knoten gleichzeitig bereitgestellt:

1. Cloud Manager bestimmt für jedes Artefakt, ob es sich um ein AEM- oder Dispatcher-Paket handelt.

2. Cloud Manager entfernt alle Dispatcher aus dem Lastenausgleich, um die Umgebung während der Bereitstellung zu isolieren.

   • Sofern nicht anders konfiguriert, können Sie Änderungen am Lastenausgleich in Entwicklungs- und Staging-Bereitstellungen überspringen, d. h. für die Entwicklungsumgebung, das Trennen und Anfügen von Schritten in beiden produktionsfremden Pipelines sowie für die Staging-Umgebung in der Produktions-Pipeline.

   

   HINWEIS

   Diese Funktion wird voraussichtlich hauptsächlich von 1-1-1-Kunden verwendet.

3. Jedes AEM-Artefakt wird über Package Manager-APIs in jeder AEM-Instanz bereitgestellt, wobei Paketabhängigkeiten die Bereitstellungsreihenfolge bestimmen.

   • Weitere Informationen dazu, wie Sie mit Paketen neue Funktionen installieren, Inhalte zwischen Instanzen übertragen und Repository-Inhalte sichern können, finden Sie im Dokument Package Manager.
   HINWEIS

   Alle AEM-Artefakte werden für Autor und Veröffentlichung bereitgestellt. Wenn knotenspezifische Konfigurationen erforderlich sind, sollten Ausführungsmodi genutzt werden. Weitere Informationen dazu, wie Sie mit Ausführungsmodi Ihre AEM-Instanz für einen bestimmten Zweck anpassen können, finden Sie im Abschnitt „Ausführungsmodi“ des Dokuments „Bereitstellen in AEM as a Cloud Service“.

4. Das Dispatcher-Artefakt wird wie folgt für jeden Dispatcher bereitgestellt:

   1. Aktuelle Konfigurationen werden gesichert und in einen temporären Speicherort kopiert.
   2. Alle Konfigurationen (mit Ausnahme der unveränderlichen Dateien) werden gelöscht. Weitere Einzelheiten finden Sie im Dokument Dispatcher-Konfigurationen. Mit diesem Schritt werden die Verzeichnisse gelöscht, damit keine verwaisten Dateien übrig bleiben.
   3. Das Artefakt wird in das httpd-Verzeichnis extrahiert. Unveränderliche Dateien werden nicht überschrieben. Alle Änderungen an unveränderlichen Dateien im Git-Repository werden bei der Bereitstellung ignoriert. Diese Dateien bilden den Kern des AMS Dispatcher-Frameworks und können nicht geändert werden.
   4. Apache führt einen Konfigurationstest durch. Wenn keine Fehler gefunden werden, wird der Service neu geladen. Falls ein Fehler auftritt, werden die Konfigurationen aus der Sicherung wiederhergestellt, der Service wird neu geladen und der Fehler wird an Cloud Manager gemeldet.
   5. Jeder in der Pipeline-Konfiguration angegebene Pfad wird ungültig oder aus dem Dispatcher-Cache entfernt.
   HINWEIS

   Cloud Manager geht davon aus, dass das Dispatcher-Artefakt alle Dateien enthält. Alle Dispatcher-Konfigurationsdateien müssen im Git-Repository vorhanden sein. Fehlende Dateien oder Ordner führen zu Bereitstellungsfehlern.

5. Nach der erfolgreichen Bereitstellung aller AEM- und Dispatcher-Pakete auf allen Knoten werden die Dispatcher wieder zum Lastenausgleich hinzugefügt und die Bereitstellung wird abgeschlossen.

   HINWEIS

   Sie können Änderungen am Lastenausgleich in Entwicklungs- und Staging-Bereitstellungen überspringen, d. h. für die Entwicklungsumgebung, das Trennen und Anfügen in beiden produktionsfremden Pipelines sowie für die Staging-Umgebung in der Produktions-Pipeline.

Bereitstellung in der Produktionsphase

Der Prozess zur Bereitstellung auf Produktionstopologien unterscheidet sich geringfügig, um die Auswirkungen auf die Besucher von AEM-Websites zu minimieren.

Produktionsbereitstellungen nutzen im Allgemeinen die oben beschriebenen Schritte, aber auf rollierende Weise:

1. AEM-Pakete werden für den Autor bereitgestellt
2. dispatcher1 wird aus dem Lastenausgleich gelöst
3. AEM-Pakete werden in publish1 und das Dispatcher-Paket parallel in dispatcher1 bereitgestellt, der Dispatcher-Cache wird geleert
4. dispatcher1 wird in den Lastenausgleich zurückgesetzt
5. Sobald dispatcher1 wieder aktiv ist, wird dispatcher2 aus dem Lastenausgleich entfernt
6. AEM-Pakete werden in publish2 und das Dispatcher-Paket parallel in dispatcher2 bereitgestellt, der Dispatcher-Cache wird geleert
7. dispatcher2 wird in den Lastenausgleich zurückgesetzt.

Dieser Vorgang wird fortgesetzt, bis die Bereitstellung alle Publisher und Dispatcher in der Topologie erreicht hat.

Notfall-Pipeline-Ausführungsmodus

In kritischen Situationen müssen Adobe Managed Services-Kunden möglicherweise Code-Änderungen in ihrer Staging- und Produktionsumgebung bereitstellen, ohne auf die Ausführung eines vollständigen Cloud Manager-Testzyklus zu warten.

Um diese Situationen zu beheben, kann die Cloud Manager-Produktions-Pipeline in einem Notfall-Modus ausgeführt werden. Wenn dieser Modus verwendet wird, werden die Sicherheits- und Leistungstestschritte nicht ausgeführt. Alle anderen Schritte, einschließlich aller konfigurierten Genehmigungsschritte, werden wie im normalen Pipeline-Ausführungsmodus ausgeführt.

Verwenden des Notfall-Pipeline-Ausführungsmodus

Wenn beim Starten der Ausführung einer Produktions-Pipeline die Funktion „Notfall-Pipeline-Ausführungsmodus“ für das Programm aktiviert wurde, können Sie über ein Dialogfeld die Ausführung im normalen Modus oder im Notfallmodus starten.

Wenn Sie die Seite mit den Pipeline-Ausführungsdetails für eine im Notfallmodus ausgeführte Ausführung anzeigen, wird in den Breadcrumbs am oberen Bildschirmrand ein Hinweis darauf angezeigt, dass die Pipeline im Notfallmodus ausgeführt wird.

Die Ausführung einer Pipeline im Notfallmodus kann auch über die Cloud Manager-API oder die CLI erfolgen. Um eine Ausführung im Notfallmodus zu starten, senden Sie mit dem Abfrageparameter ?pipelineExecutionMode=EMERGENCY eine PUT-Anfrage an den Ausführungsendpunkt der Pipeline. Alternativ haben Sie bei Verwendung der CLI folgende Möglichkeit:

$ aio cloudmanager:pipeline:create-execution PIPELINE_ID --emergency

Erneutes Ausführen der Produktionsbereitstellung

Die erneute Ausführung des Produktionsbereitstellungsschritts ist bei Ausführungen verfügbar, bei denen der Schritt zur Produktionsbereitstellung abgeschlossen ist. Die Art der Fertigstellung ist nicht wichtig. die Bereitstellung könnte erfolgreich (nur für AMS-Programme), abgebrochen oder nicht erfolgreich sein. Der Hauptanwendungsfall besteht darin, dass der Produktionsbereitstellungsschritt aus vorübergehenden Gründen fehlgeschlagen ist. Bei der erneuten Ausführung wird eine neue Ausführung mit derselben Pipeline erstellt. Diese neue Ausführung besteht aus drei Schritten:

1. Der Validierungsschritt: Dies ist im Wesentlichen die gleiche Validierung, die während einer normalen Pipeline-Ausführung erfolgt.
2. Der Build-Schritt: Im Kontext einer erneuten Ausführung kopiert der Build-Schritt Artefakte und führt keinen neuen Build-Prozess aus.
3. Der Schritt zur Produktionsbereitstellung: Er verwendet dieselbe Konfiguration und dieselben Optionen wie der Schritt zur Produktionsbereitstellung bei einer normalen Pipeline-Ausführung.

Der Build-Schritt ist in der Benutzeroberfläche möglicherweise etwas anders beschriftet, sodass zu erkennen ist, dass er Artefakte kopiert und nicht etwas neu erstellt.

Beschränkungen

• Das erneute Ausführen des Produktionsbereitstellungsschritts ist nur für die letzte Ausführung verfügbar.
• Die erneute Ausführung ist nicht für Rollback-Ausführungen oder Push-Update-Ausführungen verfügbar.
• Wenn die letzte Ausführung vor dem Produktionsbereitstellungsschritt fehlschlug, ist eine erneute Ausführung nicht möglich.

Erkennen einer erneuten Ausführung

Um festzustellen, ob es sich bei einer Ausführung um eine erneute Ausführung handelt, kann das trigger-Feld geprüft werden. Sein Wert sollte RE_EXECUTE sein.

Auslösen einer erneuten Ausführung

Um eine erneute Ausführung auszulösen, muss eine PUT-Anfrage an den HAL-Link http://ns.adobe.com/adobecloud/rel/pipeline/reExecute im Status des Produktionsbereitstellungsschritts erfolgen. Wenn dieser Link vorhanden ist, kann die Ausführung von diesem Schritt an neu gestartet werden. Wenn dies nicht der Fall ist, kann die Ausführung von diesem Schritt aus nicht erneut gestartet werden. Dieser Link ist nur im Produktionsbereitstellungsschritt vorhanden.

 {
  "_links": {
    "http://ns.adobe.com/adobecloud/rel/pipeline/logs": {
      "href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
      "templated": false
    },
    "http://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
      "href": "/api/program/4/pipeline/1/execution?stepId=2983530",
      "templated": false
    },
    "http://ns.adobe.com/adobecloud/rel/pipeline/metrics": {
      "href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/metrics",
      "templated": false
    },
    "self": {
      "href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530",
      "templated": false
    }
  },
  "id": "6187842",
  "stepId": "2983530",
  "phaseId": "1575676",
  "action": "deploy",
  "environment": "weretail-global-b75-prod",
  "environmentType": "prod",
  "environmentId": "59254",
  "startedAt": "2022-01-20T14:47:41.247+0000",
  "finishedAt": "2022-01-20T15:06:19.885+0000",
  "updatedAt": "2022-01-20T15:06:20.803+0000",
  "details": {
  },
  "status": "FINISHED"

Die Syntax des href-Wertes des HAL-Links ist nicht zu dessen Verwendung als Bezugspunkt vorgesehen. Der tatsächliche Wert sollte immer aus dem HAL-Link gelesen und nicht generiert werden.

Das Senden einer PUT-Anfrage an diesen Endpunkt führt zu einer 201-Antwort bei Erfolg, wobei der Antworttext die Darstellung der neuen Ausführung ist. Dies ähnelt dem Starten einer regulären Ausführung über die API.

Ressourcen für Business.Adobe.com