Erfahren Sie, wie Sie Code bereitstellen und was dabei in Cloud Manager passiert.
Sobald die Produktions-Pipeline einschließlich des erforderlichen Repositorys und der erforderlichen Umgebungen konfiguriert ist, kann der Code bereitgestellt werden.
Klicken Sie in Cloud Manager auf Bereitstellen, um den Bereitstellungsprozess zu starten.
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:
Sie können die Schritte verschiedener Bereitstellungsprozesse überprüfen, indem Sie die Protokolle lesen oder die Ergebnisse anhand der Testkriterien durchgehen.
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.
Der Schritt Staging-Bereitstellung umfasst die folgenden Aktionen:
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.
Der Schritt Produktionsbereitstellung umfasst die folgenden Aktionen:
Sobald die Bereitstellung abgeschlossen ist, befindet sich der Code in der Zielumgebung und Sie können die Protokolle anzeigen.
Die folgenden Schritte führen zu einer Zeitüberschreitung, wenn auf Benutzer-Feedback gewartet wird:
Schritt | Zeitüberschreitung |
---|---|
Testen der Code-Qualität | 14 Tage |
Sicherheitstests | 14 Tage |
Leistungstests | 14 Tage |
Genehmigungsantrag | 14 Tage |
Planen der Bereitstellung für die Produktion | 14 Tage |
CSE-Unterstützung | 14 Tage |
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:
Cloud Manager bestimmt für jedes Artefakt, ob es sich um ein AEM- oder Dispatcher-Paket handelt.
Cloud Manager entfernt alle Dispatcher aus dem Lastenausgleich, um die Umgebung während der Bereitstellung zu isolieren.
Diese Funktion wird voraussichtlich hauptsächlich von 1-1-1-Kunden verwendet.
Jedes AEM-Artefakt wird über Package Manager-APIs in jeder AEM-Instanz bereitgestellt, wobei Paketabhängigkeiten die Bereitstellungsreihenfolge bestimmen.
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“.
Das Dispatcher-Artefakt wird wie folgt für jeden Dispatcher bereitgestellt:
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.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.
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.
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.
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:
Dieser Vorgang wird fortgesetzt, bis die Bereitstellung alle Publisher und Dispatcher in der Topologie erreicht hat.
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.
Die Funktion „Notfall-Pipeline-Ausführungsmodus“ wird vom Customer Success Engineer auf der Programmebene aktiviert.
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
In seltenen Fällen kann es vorkommen, dass Schritte der Produktionsbereitstellung aus vorübergehenden Gründen fehlschlagen. In solchen Fällen wird die erneute Ausführung des Schritts der Produktionsbereitstellung unterstützt, solange der Schritt der Produktionsbereitstellung abgeschlossen ist, unabhängig von der Art des Abschlusses (wie zum Beispiel erfolgreich, abgebrochen oder fehlgeschlagen). Bei der erneuten Ausführung wird eine neue Ausführung mit derselben Pipeline erstellt, die aus drei Schritten besteht.
In solchen Fällen, in denen eine erneute Ausführung möglich ist, bietet die Statusseite der Produktions-Pipeline neben der üblichen Option Build-Protokoll herunterladen auch die Option Erneut ausführen.
Bei einer erneuten Ausführung wird der Build-Schritt in der Benutzeroberfläche mit dem Hinweis versehen, dass er Artefakte kopiert und nicht neu erstellt.
Zusätzlich zur Verfügbarkeit in der Benutzeroberfläche können Sie die Cloud Manager-API verwenden, um erneute Ausführungen auszulösen und Ausführungen zu identifizieren, die als erneute Ausführungen ausgelöst wurden.
Um eine erneute Ausführung auszulösen, muss eine PUT
-Anfrage an die HAL-Verknüpfung http://ns.adobe.com/adobecloud/rel/pipeline/reExecute
im Status des Schritts der Produktionsbereitstellung erfolgen.
Diese Verknüpfung ist immer nur für den Schritt der Produktionsbereitstellung verfügbar.
{
"_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 für den Wert href
der HAL-Verknüpfung ist nur ein Beispiel, und der tatsächliche Wert sollte immer aus der HAL-Verknüpfung ausgelesen 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.
Erneute Ausführungen können durch den Wert RE_EXECUTE
im Feld trigger
identifiziert werden.