Hinzufügen einer produktionsfremden Pipeline configuring-non-production-pipelines

Nachdem Sie ein Programm eingerichtet und mindestens eine Umgebung in der Cloud Manager-Benutzeroberfläche erstellt haben, können Sie produktionsfremde Pipelines hinzufügen. Mit diesen Pipelines können Sie die Code-Qualität testen, bevor Sie sie in Produktionsumgebungen bereitstellen.

Benutzende müssen über die Rolle Bereitstellungs-Manager verfügen, um produktionsfremde Pipelines konfigurieren zu können.

NOTE
Nach der Ersteinrichtung können Sie die Pipeline-Einstellungen bearbeiten.

Hinzufügen einer neuen produktionsfremden Pipeline adding-non-production-pipeline

Nachdem Sie in der Benutzeroberfläche von Cloud Manager ein Programm eingerichtet und mindestens eine Umgebung erstellt haben, können Sie produktionsfremde Pipelines hinzufügen. Verwenden Sie diese Pipelines, um die Code-Qualität zu testen, bevor Sie sie in Produktionsumgebungen bereitstellen.

So fügen Sie eine neue produktionsfremde Pipeline hinzu:

  1. Melden Sie sich unter experiece.adobe.com bei Cloud Manager an.

  2. Klicken Sie Abschnitt „Schnellzugriff auf Experience Manager.

  3. Klicken Sie im linken Panel auf Cloud Manager.

  4. Wählen Sie die gewünschte Organisation aus.

  5. Klicken Sie in Konsole Meine Programme“ auf ein Programm.

  6. Klicken Sie im linken Seitenbereich auf Pipelines.

  7. Klicken Sie auf Seite Pipelines“ oben rechts auf Pipeline hinzufügen > Produktionsfremde Pipeline hinzufügen.

    Produktionsfremde Pipeline hinzufügen

  8. Wählen Sie der Registerkarte im Dialogfeld Produktionsfremde Pipeline hinzufügen eine der folgenden produktionsfremden Pipelines aus, die Sie erstellen möchten:

    • Code-Qualitäts-Pipeline: Erstellt eine Pipeline, die den Code in einer GIT-Verzweigung erstellt, Komponententests durchführt und die Code-Qualität auswertet, ohne in einer Umgebung bereitgestellt zu werden.
    • Bereitstellungs-Pipeline: Erstellt eine Pipeline, die den Code erstellt, Komponententests durchführt, die Code-Qualität auswertet und in einer Nicht-Produktionsumgebung implementiert.

    Dialogfeld „Produktionsfremde Pipeline hinzufügen“

  9. Geben Sie Abschnitt Pipeline-Konfiguration“ in das Feld Name der produktionsfremden Pipeline eine Beschreibung für Ihre produktionsfremde Pipeline ein.

  10. Wählen im Abschnitt Bereitstellungsoptionen einen der folgenden Bereitstellungs-Trigger aus, die Sie verwenden möchten:

    • Manuell: Die Option ermöglicht es Ihnen, die Pipeline manuell zu starten.
    • Bei Git-Änderungen: Diese Option startet die Pipeline, wenn zur konfigurierten Git-Verzweigung bestätigte Änderungen hinzugefügt werden. Damit können Sie die Pipeline bei Bedarf immer noch manuell starten.
  11. Wählen Sie das Verhalten bei bedeutenden Metrikfehlern aus, das Sie verwenden möchten.

    • Jedes Mal fragen: Dieses Verhalten ist die Standardeinstellung und erfordert ein manuelles Eingreifen bei einem bedeutenden Fehler.
    • Sofortiger Ausfall: Wenn diese Option ausgewählt ist, wird die Pipeline bei einem bedeutenden Fehler abgebrochen. Im Wesentlichen wird damit ein Benutzer simuliert, der manuell jeden Fehler ablehnt.
    • Sofort fortfahren: Wenn diese Option ausgewählt ist, wird die Pipeline bei einem bedeutenden Fehler automatisch fortgesetzt. Im Wesentlichen wird damit eine Benutzerin oder ein Benutzer simuliert, die bzw. der manuell jeden Fehler genehmigt.
  12. Klicken Sie auf Weiter.

  13. Die restlichen Schritte, die Sie zum Abschließen der Konfiguration Ihrer produktionsfremden Pipeline verwenden, hängen vom Typ des Quell-Codes ab, den Sie verwenden möchten.
    Wählen Sie auf der Registerkarte Source des Dialogfelds Produktionsfremde Pipeline hinzufügen aus, welche Art von Code die produktionsfremde Pipeline verarbeiten soll.

    Weitere Informationen zu den Pipeline-Typen finden Sie unter CI/CD-Pipelines.

Ich verwende den Full-Stack-Code full-stack-code

Eine Pipeline mit Full-Stack-Code stellt gleichzeitig Backend- und Frontend-Code-Builds bereit, die ein oder mehrere AEM-Server-Programme zusammen mit der HTTPD-/Dispatcher-Konfiguration enthalten.

NOTE
Wenn für die ausgewählte Umgebung bereits eine Pipeline mit Full-Stack-Code vorhanden ist, wird diese Auswahl deaktiviert.

Gehen Sie wie folgt vor, um die Konfiguration der produktionsfremden Full-Stack-Code-Pipeline abzuschließen:

  1. Definieren Sie im Abschnitt Source Code die folgenden Optionen.

    • Mögliche Bereitstellungsumgebungen - Nur verfügbar, wenn Sie eine produktionsfremde Pipeline bearbeiten. Wenn es sich bei Ihrer Pipeline um eine Bereitstellungs-Pipeline handelt, müssen Sie auswählen, für welche Umgebungen sie etwas bereitstellen soll.

    • Repository: Wählen Sie in der Dropdown-Liste das Git-Repository aus, das die Pipeline als Quelle verwendet. Cloud Manager erstellt Code aus dem Repository, das Sie hier auswählen.

      note tip
      TIP
      Weitere Informationen dazu, wie Sie Repositorys in Cloud Manager hinzufügen und verwalten, finden Sie unter Hinzufügen und Verwalten von Repositorys.
    • Git-Verzweigung: Wählen Sie in der Dropdown-Liste die Verzweigung im ausgewählten Repository aus, aus der die Pipeline erstellen soll. Der Standardwert lautet main. Die Pipeline verwendet die ausgewählte Verzweigung als Quelle für die Erstellung und Bereitstellung. Klicken Sie bei Bedarf auf Aktualisieren, um die Liste der verfügbaren Verzweigungen für das ausgewählte Repository zu aktualisieren. Verwenden Sie diese Option, wenn eine kürzlich erstellte Verzweigung nicht in der Liste angezeigt wird.

    • Strategie erstellen

      • Vollständiger Build: Erstellt jedes Mal alle Module im Repository.

      • BETA Smart Build - Erstellt nur Module, die seit dem letzten Commit geändert wurden.
        Weitere Informationen über Verwendung von Smart Build in einer produktionsfremden Pipeline.

        note important
        IMPORTANT
        Smarter Build ist nur für Code-Qualitäts-Pipelines und Bereitstellungs-Pipelines für Entwicklungs-Full-Stack-Code verfügbar.
    • Konfiguration der Webstufe ignorieren Kontrollkästchen - Wenn diese Option aktiviert ist, stellt die Pipeline Ihre Webstufenkonfiguration nicht bereit.

  2. Im Abschnitt Pipeline können Sie, wenn es sich bei Ihrer Pipeline um eine Bereitstellungs-Pipeline handelt, eine Testphase ausführen. Aktivieren Sie die Optionen, die Sie in dieser Phase aktivieren möchten. Wenn keine der Optionen ausgewählt ist, wird die Testphase während der Pipeline-Ausführung nicht angezeigt.

    Full-Stack-Pipeline

  3. Klicken Sie auf Speichern.

Die Pipeline wird gespeichert und Sie können jetzt [Pipelines verwalten]​(managing-pipe)
lines.md) auf der Karte Pipelines auf der Seite Programmübersicht.

Ich verwende eine zielgerichtete Bereitstellung. targeted-deployment

Bei einer zielgerichteten Bereitstellung wird Code nur für ausgewählte Teile Ihrer AEM-Anwendung bereitgestellt. In einer solchen Bereitstellung können Sie auswählen, einen der folgenden Code-Typen einzuschließen:

Zielgerichtete Bereitstellungsoptionen

  • Frontend-Code – Konfigurieren Sie JavaScript und CSS für das Frontend Ihrer AEM-Anwendung.

    • Mit Frontend-Pipelines erhalten Frontend-Entwickelnde mehr Unabhängigkeit, und der Entwicklungsprozess kann beschleunigt werden.
    • Weitere Informationen dazu, wie dieser Prozess abläuft und was dabei zu beachten ist, um das volle Potenzial dieses Prozesses auszuschöpfen, finden Sie im Dokument Entwickeln von Sites mit der Frontend-Pipeline.
  • Web-Stufen-Konfiguration: Konfigurieren Sie die Dispatcher-Eigenschaften zum Speichern, Verarbeiten und Bereitstellen von Web-Seiten für den Client.

    • Weitere Informationen finden Sie im Dokument CI/CD-Pipelines.

    • Wenn für die ausgewählte Umgebung bereits eine Code-Pipeline auf Web-Ebene vorhanden ist, wird diese Auswahl deaktiviert.

    • Wenn eine Full-Stack-Pipeline bereits in einer Umgebung bereitgestellt wird, können Sie dennoch eine Web-Stufen-Konfigurations-Pipeline für dieselbe Umgebung erstellen. Dabei ignoriert Cloud Manager die Web-Stufen-Konfiguration in der Full-Stack-Pipeline.

      note note
      NOTE
      Pipelines auf Web-Ebene und Konfigurations-Pipelines werden bei privaten Repositorys nicht unterstützt. Details sowie eine vollständige Liste der Einschränkungen finden Sie unter Hinzufügen von privaten Repositorys in Cloud Manager.
  1. Definieren Sie im Abschnitt Source Code die folgenden Optionen:

    • Repository: Diese Option definiert, aus welchem GIT-Repository die produktionsfremde Pipeline den Code abrufen soll.

      note tip
      TIP
      Weitere Informationen dazu, wie Sie Repositorys in Cloud Manager hinzufügen und verwalten, finden Sie unter Hinzufügen und Verwalten von Repositorys.
    • Git-Verzweigung - Mit dieser Option wird festgelegt, von welcher Verzweigung in der ausgewählten Pipeline der Code abgerufen werden soll. Geben Sie die ersten Zeichen des Verzweigungsnamens und die Funktion zur automatischen Vervollständigung dieses Felds ein. Es werden die entsprechenden auswählbaren Verzweigungen gesucht.

    • Speicherort des Codes: Mit dieser Option wird der Pfad in der Verzweigung des ausgewählten Repositorys festgelegt, aus dem die Pipeline den Code abrufen soll.

  2. Wenn Sie das Erlebnis-Audit aktiviert haben, klicken Sie auf Weiter, um zur Registerkarte Erlebnis-Audit zu gelangen. Dort können Sie die Pfade definieren, die immer in das Erlebnis-Audit einbezogen werden sollen.

    • Wenn Sie Erlebnis-Audit aktiviert haben, finden Sie im Dokument Erlebnis-Audit Details zur Konfiguration.
    • Wenn nicht, überspringen Sie diesen Schritt.
  3. Klicken Sie auf Speichern, um die Pipeline zu speichern.

Die Pipeline wird gespeichert, und auf der Seite Programmübersicht können Sie nun über die Karte Pipelines Ihre Pipelines verwalten.

Über die Verwendung von Smart Build in einer produktionsfremden Pipeline about-smart-build-non-production-pipeline

Smart Build in Cloud Manager ist eine optimierte Build-Strategie für produktionsfremde Pipelines. Smartes Erstellen reduziert Build-Zeiten, indem Module zwischengespeichert und nur die Module neu erstellt werden, die seit der letzten erfolgreichen Ausführung geändert wurden. Unveränderte Module werden aus dem Cache wiederverwendet, während nur geänderte Module und ihre Abhängigkeiten neu erstellt werden, was die Effizienz für Workflows für die iterative Entwicklung verbessert.

Smart Build ist derzeit nur für Folgendes verfügbar:

  • Code-Qualitäts-Pipelines
  • Entwickeln Sie Full-Stack-Bereitstellungs-Pipelines.
NOTE
Die erste Ausführung nach der Aktivierung von Smart Build verhält sich wie ein vollständiger Build, da der Cache leer ist.

Smartes Erstellen wird empfohlen, wenn Folgendes zutrifft:

  • Sie entwickeln aktiv und nehmen häufige inkrementelle Änderungen vor.
  • Ihr Projekt enthält mehrere Maven-Module.
  • Vollständige Builds beanspruchen viel Zeit.

Smartes Erstellen ist nicht immer ideal, wenn Folgendes zutrifft:

  • Ihr Build beruht in hohem Maße auf Plug-ins, die Vorgänge außerhalb des Abhängigkeitsdiagramms von Maven durchführen.
  • Sie benötigen bei jeder Ausführung eine vollständige Neuaufbauvalidierung.

Grundlegendes zur Build-Leistung smart-build-performance

Der Leistungsgewinn durch die Verwendung von Smart Build hängt von mehreren Faktoren ab, darunter den folgenden:

  • Die Anzahl der Module im Projekt.
  • Häufigkeit und Umfang von Code-Änderungen.
  • Die Verteilung von Abhängigkeiten über Module hinweg.

Im Allgemeinen können Projekte mit vielen unabhängigen Modulen die größte Verbesserung verzeichnen.

Opt-out aus dem Cache pro Modul smart-build-cache-optout

Smart Build bietet eine differenzierte Steuerung, mit der Sie das Caching für bestimmte Module deaktivieren können. Diese Funktion ist nützlich, wenn bestimmte Module:

  • Verwenden Sie Plug-ins wie exec-maven-plugin oder maven-antrun-plugin.
  • Führen Sie Dateivorgänge aus, die nicht von Maven-Abhängigkeiten verfolgt werden.
  • Zwischengespeicherte Inhalte führen zu inkonsistenten Ergebnissen.

Deaktivieren der Zwischenspeicherung für ein Modul smart-build-disable-caching

Sie können die folgende Eigenschaft zum pom.xml des betroffenen Moduls hinzufügen:

<properties>
  <maven.build.cache.enabled>false</maven.build.cache.enabled>
</properties>

Diese Syntax zwingt das Modul bei jeder Pipeline-Ausführung neu zu erstellen, während andere Module weiterhin vom Caching profitieren.

Einschränkungen und Überlegungen bei der Verwendung von Smart Build smart-build-limitations

Beachten Sie bei der Verwendung von Smart Build Folgendes:

  • Smarter Build beruht auf Maven-Abhängigkeitsanalyse.
  • Bei Änderungen außerhalb des Abhängigkeitsdiagramms werden Trigger-Neuaufbauten möglicherweise nicht unterstützt.
  • Einige Plug-ins sind möglicherweise nicht vollständig mit der Zwischenspeicherung kompatibel.
  • Sie können jederzeit wieder zu Vollständiger Build wechseln, indem Sie die produktionsfremde Pipeline bearbeiten.

Wenn Sie auf unerwartetes Build-Verhalten stoßen, sollten Sie das Caching für bestimmte Module deaktivieren oder Ihre Build-Strategie vorübergehend auf Vollständiger Build umstellen.

Fehlerbehebung bei Problemen mit Smart Build smart-build-troubleshoot

Problem
Lösungsvorschläge
Buildergebnisse sind inkonsistent
・ Deaktiviert die Zwischenspeicherung für betroffene Module.
・ Überprüfen des Plug-in-Verhaltens (insbesondere exec/antrun Plug-ins).
Keine Leistungsverbesserung
・ Stellen Sie sicher, dass mehrere Durchgänge stattgefunden haben (Aufwärmen des Cache).
・ Überprüfen Sie, ob die meisten Module häufig wechseln.
Unerwartete Artefakte oder fehlende Änderungen
・ Überprüfen, ob Änderungen außerhalb der Maven-Abhängigkeitsverfolgung liegen.
・ Verwenden Sie Vollständiger Build zur Überprüfung.

Siehe Hinzufügen einer produktionsfremden Pipeline um die intelligente Erstellung zu aktivieren.

Dispatcher-Pakete ausschließen exclude-dispatcher-packages

Wenn Sie möchten, dass Dispatcher-Pakete in Ihrer Pipeline erstellt, aber nicht in den Build-Speicher hochgeladen werden, deaktivieren Sie die Veröffentlichung. Dadurch kann die Laufzeit der Pipeline verkürzt werden.

Fügen Sie Ihrer Projekt-pom.xml-Datei die folgende Konfiguration hinzu, um die Veröffentlichung von Dispatcher-Paketen zu deaktivieren. Legen Sie eine Umgebungsvariable im Cloud Manager-Build-Container fest, um zu kennzeichnen, wann Dispatcher-Pakete ignoriert werden sollen. Die Pipeline liest dieses Flag und ignoriert sie entsprechend.

<profile>
  <id>only-include-dispatcher-when-it-isnt-ignored</id>
  <activation>
    <property>
      <name>env.IGNORE_DISPATCHER_PACKAGES</name>
      <value>[!NOTE]rue</value>
    </property>
  </activation>
  <modules>
    <module>dispatcher</module>
  </modules>
</profile>
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab