Bereitstellen für AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Letzte Aktualisierung: 30. September 2026

Gilt für:
Experience Manager as a Cloud Service

Themen:
Deploying

Erstellt für:

Admin

Einführung introduction

Die Grundlagen der Code-Entwicklung in AEM as a Cloud Service ähneln denen von AEM On-Premise- und Managed Services-Lösungen. Entwicklerinnen und Entwickler schreiben Code und testen ihn lokal, bevor sie ihn an Remote-Umgebungen auf AEM as a Cloud Service pushen. Dafür wird Cloud Manager benötigt, das ein optionales Tool zur Inhaltsbereitstellung für Managed Services war. Dieses Bereitstellungs-Tool ist nun das einzige Verfahren für die Bereitstellung von Code in Entwicklungs-, Staging- und Produktionsumgebungen von AEM as a Cloud Service. Zur schnellen Funktionsüberprüfung und zum Debugging vor der Bereitstellung der oben genannten Umgebungen kann der Code von einer lokalen Umgebung mit einer schnellen Entwicklungsumgebung synchronisiert werden.

Die Aktualisierung der AEM-Version ist stets ein separates Bereitstellungsereignis, das nicht mit dem Pushen von anwenderspezifischem Code verbunden ist. Alternativ sollten benutzerdefinierte Code-Versionen anhand der AEM-Version getestet werden, die sich in der Produktionsumgebung befindet, da sie auf dieser bereitgestellt wird. AEM-Versionsaktualisierungen, die danach erfolgen (häufig und automatisch angewendet), sollen abwärtskompatibel mit dem bereits bereitgestellten Kunden-Code sein.

Im Rest dieses Dokuments wird beschrieben, wie Entwickler ihre Vorgehensweisen anpassen, um sowohl mit AEM as a Cloud Service-Versionsaktualisierungen als auch mit Kundenaktualisierungen zu arbeiten.

Kundenveröffentlichungen customer-releases

Code-Entwicklung für die richtige AEM-Version coding-against-the-right-aem-version

Bei früheren AEM-Lösungen änderte sich die AEM-Version selten, und Kunden aktualisierten die Produktionsinstanzen auf den neuesten Schnellstart, indem sie auf das API-JAR verwiesen. Anwendungen auf AEM as a Cloud Service werden jedoch häufiger automatisch auf die neueste Version von AEM aktualisiert. Daher sollte benutzerdefinierter Code für interne Releases mit der neuesten AEM-Version erstellt werden.

Wie bei bestehenden Nicht-Cloud-AEM-Versionen wird die lokale Offline-Entwicklung basierend auf einem bestimmten Schnellstart unterstützt und normalerweise als primäres Debugging-Tool erwartet.

NOTE

Es gibt geringfügige betriebliche Unterschiede zwischen dem Verhalten der Anwendung auf einem lokalen Computer und der Adobe-Cloud-Infrastruktur. Diese architektonischen Unterschiede müssen bei der lokalen Entwicklung berücksichtigt werden und führen zu einem anderen Verhalten bei der Bereitstellung in der Cloud-Infrastruktur. Aufgrund dieser Unterschiede ist es wichtig, umfassende Tests in Entwicklungs- und Staging-Umgebungen durchzuführen, bevor neuer benutzerdefinierter Code in der Produktion eingeführt wird.

Um benutzerdefinierten Code für eine interne Version zu entwickeln, sollte die entsprechende Version des AEM as a Cloud Service-SDK heruntergeladen und installiert werden. Weitere Informationen zur Verwendung der AEM as a Cloud Service-Dispatcher-Tools finden Sie unter Dispatcher in der Cloud.

Das folgende Video bietet einen Überblick über die Bereitstellung von Code für AEM as a Cloud Service:

https://video.tv.adobe.com/v/33376?captions=ger&quality=9&learn=on

Bereitstellen von Inhaltspaketen über Cloud Manager und Package Manager deploying-content-packages-via-cloud-manager-and-package-manager

Bereitstellungen über Cloud Manager deployments-via-cloud-manager

Kundinnen und Kunden stellen benutzerdefinierten Code über Cloud Manager in Cloud-Umgebungen bereit. Cloud Manager wandelt lokal assemblierte Inhaltspakete in ein Artefakt um, das dem Sling-Funktionsmodell entspricht. Dieses Modell beschreibt eine Anwendung auf AEM as a Cloud Service, wenn sie in einer Cloud-Umgebung ausgeführt wird. Wenn Sie die Pakete im Paket-Manager für Cloud-Umgebungen betrachten, können Sie deswegen feststellen, dass der Name „cp2fm“ enthält und alle Metadaten der umgewandelten Pakete entfernt wurden. Mit ihnen kann nicht interagiert werden, d. h. sie können nicht heruntergeladen, repliziert oder geöffnet werden. Eine ausführliche Dokumentation zum Konvertierer finden Sie unter sling-org-apache-sling-feature-cpconverter auf GitHub.

Inhaltspakete für AEM as a Cloud Service müssen unveränderliche und veränderliche Inhalte trennen. Cloud Manager installiert nur den veränderlichen Inhalt und gibt eine Nachricht wie die folgende aus:

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

Im Rest dieses Abschnitts werden die Zusammensetzung und die Auswirkungen unveränderlicher bzw. veränderlicher Pakete beschrieben.

Unveränderliche Inhaltspakete immutabe-content-packages

Sämtlicher Content und Code, der im unveränderlichen Repository gespeichert ist, muss in Git eingecheckt und über Cloud Manager bereitgestellt werden. Anders gesagt: Im Gegensatz zu aktuellen AEM-Lösungen wird Code niemals direkt auf einer laufenden AEM-Instanz bereitgestellt. Durch diesen Workflow wird sichergestellt, dass der Code, der für eine bestimmte Version in beliebigen Cloud-Umgebungen ausgeführt wird, identisch ist. So wird das Risiko unbeabsichtigter Code-Varianten in der Produktion eliminiert. Beispielsweise sollte die OSGi-Konfiguration in die Quell-Code-Verwaltung eingecheckt werden, anstatt zur Laufzeit über den Konfigurations-Manager der AEM-Web-Konsole verwaltet zu werden.

Ein Schalter ermöglicht Anwendungsänderungen aufgrund des Bereitstellungsmusters, sodass sie sich nicht auf Änderungen im veränderlichen Repository mit Ausnahme von Service-Benutzern, ihren ACLs, Knotentypen und Änderungen der Indexdefinition verlassen können.

Kundinnen und Kunden mit vorhandener Code-Basis müssen die in der AEM-Dokumentation beschriebene Repository-Umstrukturierung durchführen, um dafür zu sorgen, dass die zuvor unter „/etc“ befindlichen Inhalte an den richtigen Speicherort verschoben werden.

Für diese Code-Pakete gelten einige zusätzliche Einschränkungen, z. B. werden keine Installations-Hooks unterstützt.

OSGi-Konfiguration osgi-configuration

Wie bereits erwähnt, sollte die OSGi-Konfiguration in die Quell-Code-Verwaltung eingecheckt werden und nicht über die Web-Konsole. Zu geeigneten Verfahren gehören:

Vornehmen der erforderlichen Änderungen in der lokalen AEM-Umgebung des Entwicklers mit dem Konfigurations-Manager der AEM-Web-Konsole und anschließendes Exportieren der Ergebnisse in das AEM-Projekt im lokalen Dateisystem;
Manuelles Erstellen der OSGi-Konfiguration im AEM-Projekt im lokalen Dateisystem und anschließendes Verweisen auf die Eigenschaftsnamen durch den Konfigurations-Manager der AEM-Konsole.

Weitere Informationen zur OSGi-Konfiguration finden Sie unter Konfigurieren von OSGi für AEM as a Cloud Service.

Veränderlicher Inhalt mutable-content

Manchmal ist es nützlich, Inhaltsänderungen in der Quell-Code-Verwaltung vorzubereiten, damit Cloud Manager sie bereitstellt, sobald eine Umgebung aktualisiert wird. Beispielsweise ist es sinnvoll, bestimmte Stammordnerstrukturen zu testen. Richten Sie Änderungen in bearbeitbaren Vorlagen ein, um Richtlinien und Komponenten zu aktivieren, die von der Anwendungsbereitstellung aktualisiert werden.

Cloud Manager stellt Inhalte mithilfe zweier Strategien für das veränderliche Repository bereit: veränderliche Inhaltspakete und repoinit.

Veränderliche Inhaltspakete mutable-content-packages

Inhalte wie Ordnerpfadhierarchien, Service-Benutzer und Zugangssteuerungen (ACLs) werden in der Regel in ein AEM-Projekt übertragen, das auf Maven-Archetypen basiert. Zu den Methoden gehören das Exportieren aus AEM oder das direkte Schreiben als XML. Bei der Erstellung und Bereitstellung packt Cloud Manager das resultierende veränderliche Inhaltspaket. Die veränderbaren Inhalte werden in der Bereitstellungsphase in der Pipeline zu drei verschiedenen Zeitpunkten installiert:

Vor dem Start der neuen Version des Programms:

Indexdefinitionen (hinzufügen, ändern, entfernen)

Beim Start der neuen Version des Programms, aber vor der Umstellung:

Service-Benutzer (hinzufügen)
ACLs für Service-Benutzer (hinzufügen)
Knotentypen (hinzufügen)

Nach der Umstellung auf die neue Programmversion:

Alle anderen Inhalte, die über Jackrabbit-Vault definiert werden können. Beispiel:
- Ordner (hinzufügen, ändern, entfernen)
- Bearbeitbare Vorlagen (hinzufügen, ändern, entfernen)
- Kontextsensible Konfiguration (alles unter /conf) (hinzufügen, ändern, entfernen)
- Skripte (Pakete können Trigger-Installations-Hooks enthalten). Siehe Jackrabbit filevault-).

Die Installation veränderlicher Inhalte in Autoren- oder Veröffentlichungsinstanzen lässt sich einschränken, indem Sie Pakete unter /apps in einen „install.author“- oder „install.publish“-Ordner einbetten. Eine Umstrukturierung, die dieser Trennung Rechnung trägt, wurde in AEM 6.5 vorgenommen. Einzelheiten zur empfohlenen Projektumstrukturierung finden Sie in der Dokumentation zu AEM 6.5.

NOTE

Inhaltspakete werden für alle Umgebungstypen (dev, stage, prod) bereitgestellt. Die Bereitstellung kann nicht auf eine bestimmte Umgebung beschränkt werden. Diese Einschränkung dient dazu, einen Testlauf der automatischen Ausführung zu ermöglichen. Umgebungsspezifische Inhalte müssen manuell über den Paket-Manager installiert werden.

Außerdem gibt es keinen Mechanismus zum Zurücksetzen der Änderungen des veränderlichen Inhaltspakets, nachdem sie angewendet wurden. Wenn Kundinnen oder Kunden ein Problem entdecken, können sie es in ihrer nächsten Code-Version beheben oder – als letzte Möglichkeit – das ganze System auf einen Zeitpunkt vor der Bereitstellung zurücksetzen.

Alle enthaltenen Pakete von Drittanbietern müssen als AEM as a Cloud Service-kompatibel validiert werden. Andernfalls führt ihre Einbeziehung zu einem Bereitstellungsfehler.

Wie bereits erwähnt, entsprechen Kunden mit bestehender Code-Basis der Repository-Umstrukturierung, die für die in der Dokumentation zu AEM 6.5 beschriebenen 6.5-Repository-Änderungen erforderlich .

Repoinit repoinit

In folgenden Fällen ist es vorzuziehen, in den OSGi-Werkseinstellungen manuell explizite repoinit zu codieren:

Service-Benutzer erstellen/löschen/deaktivieren
Gruppen erstellen/löschen
Benutzer erstellen/löschen

ACLs hinzufügen

note
NOTE
Eine Definition von ACLs erfordert, dass die Knotenstrukturen bereits vorhanden sind. Daher sind vorherige Anweisungen zum Erstellen von Pfaden erforderlich.

Pfad hinzufügen (z. B. für Stammordnerstrukturen)
CNDs hinzufügen (Definitionen für Knotentypen)

Aufgrund der folgenden Vorteile ist „repoinit“ für diese unterstützten Anwendungsfälle zur Content-Änderung vorzuziehen:

Repoinit erstellt Ressourcen beim Start, sodass Logik die Existenz dieser Ressourcen als selbstverständlich betrachten kann. Beim Ansatz mit veränderlichen Inhaltspaketen werden Ressourcen nach dem Start erstellt, sodass Anwendungs-Code, der auf sie angewiesen ist, fehlschlägt.
Repoinit ist ein relativ sicherer Anweisungssatz, da Sie explizit steuern, welche Aktion vorgenommen werden soll. Zudem werden nur additive Vorgänge unterstützt, mit Ausnahme einiger sicherheitsrelevanter Fälle, in denen Benutzende, Dienst-Benutzende und Gruppen entfernt werden können. Dagegen ist eine Entfernung beim Ansatz mit veränderlichen Inhaltspaketen explizit. Wenn Sie einen Filter definieren, werden alle von einem Filter derzeit erfassten Elemente gelöscht. Dennoch ist Vorsicht geboten, da es bei jedem Inhalt Szenarien geben kann, in denen die Existenz neuer Inhalte das Verhalten des Programms verändert.
Repoinit sorgt für schnelle und atomische Operationen. Veränderliche Inhaltspakete hingegen können stark von der Leistung der Strukturen abhängen, die von einem Filter abgedeckt werden. Selbst wenn Sie nur einen Knoten aktualisieren, wird ein Schnappschuss einer großen Baumstruktur erstellt.
repoinit-Anweisungen können in einer lokalen Entwicklungsumgebung zur Laufzeit überprüft werden, da sie bei der Registrierung der OSGi-Konfiguration ausgeführt werden.
Repoinit-Anweisungen sind atomisch und explizit und werden übersprungen, wenn der Status bereits übereinstimmt.

Wenn Cloud Manager die Anwendung bereitstellt, werden diese Anweisungen unabhängig von der Installation jeglicher Inhaltspakete ausgeführt.

So erstellen Sie repoinit:

Fügen Sie die OSGi-Konfiguration für werksmäßige PID org.apache.sling.jcr.repoinit.RepositoryInitializer in einem Konfigurationsordner des Projekts hinzu. Verwenden Sie einen beschreibenden Namen für die Konfiguration wie org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure.
Fügen Sie repoinit-Anweisungen in die Skript-Eigenschaft der Konfiguration ein. Syntax und Optionen werden in der Sling-Dokumentation beschrieben. Erstellen Sie einen übergeordneten Ordner explizit vor den untergeordneten Ordnern. Beispielsweise ist eine explizite Erstellung von /content vor /content/myfolder und von letzterem vor /content/myfolder/mysubfolder erforderlich. Bei ACLs, die für untergeordnete Strukturen festgelegt werden, wird empfohlen, diese auf einer höheren Ebene festzulegen und eine Einschränkung rep:glob zu verwenden. Beispiel: (allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs)).
Validieren Sie zur Laufzeit in der lokalen Entwicklungsumgebung.

WARNING

Bei ACLs, die für Knoten unter /apps oder /libs definiert sind, beginnt die repoinit-Ausführung in einem leeren Repository. Die Pakete werden nach repoinit installiert. Das bedeutet, dass Anweisungen sich auf nichts verlassen können, was in den Paketen definiert ist, sondern Vorbedingungen wie die übergeordneten Strukturen darunter definieren müssen.

TIP

Bei ACLs ist die Erstellung tiefer Strukturen komplex. Daher ist es sinnvoller, eine ACL auf einer höheren Ebene zu definieren und dann durch eine Einschränkung rep:glob zu begrenzen, wo sie wirken soll.

Weitere Einzelheiten über repoinit finden Sie in der Sling-Dokumentation

Einmalige Pakete des Paket-Managers für Pakete mit veränderlichen Inhalten package-manager-oneoffs-for-mutable-content-packages

Es gibt Anwendungsfälle, in denen ein Inhaltspaket als „einmalige“ Installation installiert werden sollte. Zum Beispiel beim Importieren bestimmter Inhalte aus der Produktions- in die Staging-Umgebung, um ein Problem in der Produktion zu debuggen. Für solche Szenarien kann der Paket-Manager in Umgebungen mit AEM as a Cloud Service verwendet werden.

Package Manager ist ein Laufzeitkonzept. Es ist nicht möglich, Inhalte oder Code im unveränderlichen Repository zu installieren, und diese Inhaltspakete bestehen aus veränderlichen Inhalten (hauptsächlich /content oder /conf). Wenn das Inhaltspaket gemischte Inhalte enthält, d. h. sowohl veränderliche als auch unveränderliche, werden nur die veränderlichen Inhalte installiert.

IMPORTANT

Die Benutzeroberfläche von Package Manager gibt die Fehlermeldung undefiniert zurück, wenn die Installation eines Pakets länger als zehn Minuten dauert.

Diese Zeit ist nicht auf einen Fehler bei der Installation zurückzuführen, sondern auf einen Timeout, den Cloud Service für alle Anfragen hat.

Wiederholen Sie die Installation nicht, wenn ein solcher Fehler auftritt. Die Installation wird im Hintergrund korrekt ausgeführt. Wenn Sie die Installation neu starten, führen mehrere gleichzeitige Importvorgänge zu Konflikten.

Alle von Cloud Manager installierten Inhaltspakete (sowohl veränderliche als auch unveränderliche) erscheinen in der Benutzeroberfläche von AEM Package Manager eingefroren. Diese Pakete können weder neu installiert, neu erstellt noch heruntergeladen werden und werden mit dem Suffix „cp2fm“ aufgeführt, was darauf hinweist, dass Cloud Manager die Installation durchgeführt hat.

Einschließen von Drittanbieterpaketen including-third-party

Es kommt häufig vor, dass Kundinnen und Kunden vorgefertigte Pakete aus Drittanbieterquellen (zum Beispiel von Software-Anbietern wie Übersetzungspartnern von Adobe) einbeziehen. Es wird empfohlen, diese Pakete in einem Remote-Repository zu hosten und in pom.xml auf sie zu verweisen. Diese Methode ist für öffentliche Repositorys und auch für private Repositorys mit Kennwortschutz möglich, wie unter Unterstützung für kennwortgeschützte Maven-Repositorys beschrieben.

Wenn das Speichern des Pakets in einem Remote-Repository nicht möglich ist, können Kundinnen und Kunden es in einem lokalen, dateisystembasierten Maven-Repository ablegen, das als Teil des Projekts in SCM eingecheckt wird. Alles, was davon abhängt, verweist darauf. Das Repository wird in diesem Fall wie im nachfolgend dargestellten POM des Projekts deklariert:

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Alle enthaltenen Pakete von Drittanbietern müssen den in diesem Artikel beschriebenen Richtlinien zur Kodierung und Verpackung von AEM as a Cloud Service entsprechen. Andernfalls führt ihre Einbeziehung zu einem Bereitstellungsfehler.

Das folgende Maven-Fragment POM.xml zeigt, wie Drittanbeiter-Pakete über die Maven-Plug-in-Konfiguration filevault-package-maven-plugin in das „Container“-Paket des Projekts, in der Regel „all“ genannt, eingebettet werden können.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Funktionsweise von rollierenden Bereitstellungen how-rolling-deployments-work

Wie AEM-Aktualisierungen werden auch Kunden-Releases mithilfe einer rollierenden Bereitstellungsstrategie bereitgestellt, um unter den entsprechenden Bedingungen Ausfallzeiten im Author-Cluster zu vermeiden. Im Folgenden wird die allgemeine Ereignisabfolge beschrieben, bei der Knoten mit der alten und der neuen Version des Kunden-Codes dieselbe Version des AEM-Codes ausführen.

TIP

Als Alternative zu einer standardmäßigen rollierenden Bereitstellung können Sie eine Canary-Bereitstellung verwenden, um einen neuen Build auf der Produktionsinfrastruktur zu validieren, bevor Sie Live-Traffic an diese weiterleiten. Siehe Verwenden von Canary-Bereitstellungen zum Überprüfen von Code.

Knoten mit der alten Version sind aktiv, und ein Freigabekandidat für die neue Version wird erstellt und verfügbar gemacht.
Wenn neue oder aktualisierte Indexdefinitionen vorhanden sind, werden die entsprechenden Indizes verarbeitet. Knoten mit der alten Version verwenden immer die alten Indizes, während Knoten mit der neuen Version immer die neuen Indizes verwenden.
Knoten mit der neuen Version starten, während alte Versionen weiterhin Traffic bereitstellen.
Knoten mit der alten Version laufen weiter und bedienen weiterhin den Traffic, während Knoten mit der neuen Version mithilfe von Integritätsprüfungen auf ihre Bereitschaft überprüft werden.
Knoten mit der neuen Version, die bereit sind, nehmen den Traffic an und ersetzen die Knoten mit der alten Version, die heruntergefahren werden.
Im Laufe der Zeit ersetzen Knoten mit der neuen Version Knoten durch die alte Version, bis nur Knoten mit neuen Versionen verbleiben, wodurch die Bereitstellung abgeschlossen wird.
Alle neuen oder geänderten veränderlichen Inhalte werden dann bereitgestellt.

Indizes indexes

Neue oder geänderte Indizes verursachen einen zusätzlichen Indizierungs- oder Neuindizierungsschritt, bevor die neue Version den Traffic aufnehmen kann. Details zur Indexverwaltung in AEM as a Cloud Service finden Sie in unter Inhaltssuche und -indizierung. Sie können den Indizierungsstatus von Build-Seiten in Cloud Manager überprüfen und eine Benachrichtigung erhalten, wenn die neue Version für Traffic bereit ist.

NOTE

Die für eine rollierende Bereitstellung benötigte Zeit hängt von der Größe des Index ab. Der Grund dafür ist, dass die neue Version keinen Traffic akzeptieren kann, bis der neue Index generiert wird.

Derzeit funktioniert AEM as a Cloud Service nicht mit Indexverwaltungs-Tools wie dem ACS Commons Ensure Oak Index-Tool.

Replikation replication

Der Veröffentlichungsmechanismus ist rückwärtskompatibel mit den AEM Replication Java™-APIs.

Verwenden Sie zum Entwickeln und Testen der Replikation mit dem Cloud-fähigen AEM-Schnellstart die klassischen Replikationsfunktionen mit einer Autoren-/Veröffentlichungsinstanz. Wenn der Einstiegspunkt der Benutzeroberfläche auf AEM Author für die Cloud entfernt wird, gehen die Benutzenden für die Konfiguration zu http://localhost:4502/etc/replication.

Abwärtskompatibler Code für rollierende Bereitstellungen backwards-compatible-code-for-rolling-deployments

Wie oben beschrieben impliziert die kontinuierliche Bereitstellungsstrategie von AEM as a Cloud Service, dass sowohl die alte als auch die neue Version gleichzeitig ausgeführt werden. Seien Sie daher vorsichtig bei Code-Änderungen, die nicht abwärtskompatibel mit der alten, noch funktionsfähigen AEM-Version sind.

Darüber hinaus sollte die alte Version auf Kompatibilität mit allen neuen Strukturen für veränderliche Inhalte getestet werden, die von der neuen Version angewendet werden, wenn ein Rollback stattfindet, da veränderliche Inhalte nicht entfernt werden.

Service-Benutzer und ACL-Änderungen service-users-and-acl-changes

Das Ändern von Service-Benutzern oder ACLs, die auf Inhalte oder Code zugreifen, führt in den älteren AEM-Versionen zu Fehlern, die den Zugriff auf diese Inhalte oder diesen Code bei veralteten Service-Benutzern zur Folge haben. Um diesem Verhalten entgegenzuwirken, wird empfohlen, die Änderungen auf mindestens zwei Versionen zu verteilen, wobei die erste Version als Bindeglied fungiert, bevor in der folgenden Version bereinigt wird.

Indexänderungen index-changes

Bei Änderungen an Indizes ist es wichtig, dass die alte Version ihre Indizes bis zum Ende weiter verwendet, während die neue Version ihre eigenen geänderten Indizes nutzt. Der Entwickler befolgt die unter „Inhaltssuche und -indizierung beschriebenen Methoden zur .

Konservative Kodierung für Rollbacks conservative-coding-for-rollbacks

Wenn nach der Bereitstellung ein Fehler gemeldet oder erkannt wird, ist möglicherweise ein Rollback zur alten Version erforderlich. Stellen Sie sicher, dass der neue Code mit allen neuen Strukturen kompatibel ist, die von dieser neuen Version erstellt wurden, da die neuen Strukturen (alle veränderlichen Inhalte) nicht zurückgesetzt werden. Wenn der alte Code nicht kompatibel ist, müssen die Korrekturen in späteren Kundenversionen vorgenommen werden.

Schnelle Entwicklungsumgebungen (RDE) rde

Schnelle Entwicklungsumgebungen (oder RDEs) ermöglichen es Entwicklerinnen und Entwicklern, Änderungen schnell bereitzustellen und zu überprüfen. Dadurch wird der Zeitaufwand für das Testen von Funktionen minimiert, die nachweislich in einer lokalen Entwicklungsumgebung funktionieren.

Im Gegensatz zu normalen Entwicklungsumgebungen, die Code über die Cloud Manager-Pipeline bereitstellen, verwenden Entwicklerinnen und Entwickler Befehlszeilen-Tools, um Code aus einer lokalen Entwicklungsumgebung mit der RDE zu synchronisieren. Nachdem die Änderungen erfolgreich in einer RDE getestet wurden, stellen Sie sie über die Cloud Manager-Pipeline in einer regulären Cloud-Entwicklungsumgebung bereit, wodurch der Code die entsprechenden Qualitätsprüfungen durchläuft.

Ausführungsmodi runmodes

In bestehenden AEM-Lösungen haben Kunden die Möglichkeit, Instanzen mit beliebigen Ausführungsmodi auszuführen und OSGi-Konfigurationen anzuwenden oder OSGi-Pakete in diesen spezifischen Instanzen zu installieren. Zu den definierten Ausführungsmodi gehören normalerweise der Service (Autor und Veröffentlichen) sowie die Umgebung (RDE, dev, stage, prod).

AEM as a Cloud Service hingegen legt genauer fest, welche Ausführungsmodi verfügbar sind und wie OSGi-Pakete und OSGi-Konfigurationen ihnen zugeordnet werden können:

OSGi-Konfigurations-Ausführungsmodi müssen für die Umgebung auf RDE, Entwicklung, Staging oder Produktion und für den Service auf Author oder Publish verweisen. Es wird eine Kombination von <service>.<environment_type> unterstützt, bei denen diese Umgebungen in dieser bestimmten Reihenfolge verwendet werden müssen (z. B. author.dev oder publish.prod). Auf die OSGi-Token sollte direkt im Code verwiesen werden, da die getRunModes-Methode zur Laufzeit den Umgebungstyp nicht mehr enthält. Weitere Informationen finden Sie unter Konfigurieren von OSGi für AEM as a Cloud Service.
Die Ausführungsmodi von OSGi-Paketen sind auf den Service (author, publish) beschränkt. OSGi-Pakete für den Pre-Run-Modus sollten im Inhaltspaket unter install.author oder install.publish installiert werden.

AEM as a Cloud Service lässt die Verwendung von Ausführungsmodi nicht zu, um Inhalte für bestimmte Umgebungen oder Dienste zu installieren. Wenn eine Entwicklungsumgebung mit Daten oder HTML bestückt werden muss, die sich nicht in der Staging- oder Produktionsumgebung befinden, kann der Paket-Manager verwendet werden.

Folgende Konfigurationen für den Ausführungsmodus werden unterstützt:

config (der Standard, gilt für alle AEM-Services)
config.author (gilt für alle AEM Author-Services)
config.author.dev (gilt für den AEM Dev Author-Service)
config.author.rde (Gilt für AEM RDE Autor-Service)
config.author.stage (gilt für den AEM Staging Author-Service)
config.author.prod (gilt für den AEM Production Author-Service)
config.publish (gilt für den AEM Publish-Service)
config.publish.dev (gilt für den AEM Dev Publish-Service)
config.publish.rde (Gilt für AEM-RDE Publish-Service)
config.publish.stage (gilt für den AEM Staging Publish-Service)
config.publish.prod (gilt für den AEM Production Publish-Service)
config.dev (gilt für AEM-Dev-Services)
config.rde (Gilt für RDE-Services)
config.stage (gilt für AEM-Staging-Services)
config.prod (gilt für AEM-Produktions-Services)

Es wird jene OSGi-Konfiguration verwendet, die über die meisten passenden Ausführungsmodi verfügt.

Bei der lokalen Entwicklung wird ein Ausführungsmodus-Startparameter -r verwendet, um die OSGi-Konfiguration für den Ausführungsmodus anzugeben.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Konfiguration von Wartungsaufgaben in der Quell-Code-Verwaltung maintenance-tasks-configuration-in-source-control

Die Konfiguration von Wartungsaufgaben muss in der Quell-Code-Verwaltung persistiert werden, da der Bildschirm Tools > Vorgänge in Cloud-Umgebungen nicht mehr verfügbar ist. Dadurch wird sichergestellt, dass Änderungen vorsätzlich persistiert werden, anstatt reaktiv angewendet und dann vergessen zu werden. Weitere Informationen finden Sie unter Wartungsaufgaben in AEM as a Cloud Service.

recommendation-more-help

experience-manager-cloud-service-help-main-toc