Build-Umgebung

Erfahren Sie mehr über die Build-Umgebung von Cloud Manager und darüber, wie sie den Code erstellt und testet.

Details der Build-Umgebung

Cloud Manager erstellt und testet Ihren Code mithilfe einer speziellen Erstellungsumgebung.

  • Die Erstellungsumgebung ist Linux-basiert und von Ubuntu 18.04 abgeleitet.

  • Apache Maven 3.6.0 ist installiert.

  • Die installierten Java-Versionen sind Oracle JDK 8u202 und Oracle JDK 11.0.2.

  • Standardmäßig wird die Umgebungsvariable JAVA_HOME auf /usr/lib/jvm/jdk1.8.0_202 festgelegt, was Oracle JDK 8u202 enthält. Weitere Einzelheiten finden Sie im Abschnitt Alternative Maven-Ausführung JDK-Version.

  • Es sind einige zusätzliche erforderliche Systempakete installiert.

    • bzip2
    • unzip
    • libpng
    • imagemagick
    • graphicsmagick
  • Andere Pakete können zur Build-Zeit installiert werden, wie im Abschnitt Installieren zusätzlicher Systempakete beschrieben.

  • Jeder Build wird in einer unberührten Umgebung erstellt, der Build-Container speichert zwischen den Ausführungen keinen Status.

  • Maven wird immer mit den folgenden drei Befehlen ausgeführt.

  • mvn --batch-mode org.apache.maven.plugins:maven-dependency-plugin:3.1.2:resolve-plugins

  • mvn --batch-mode org.apache.maven.plugins:maven-clean-plugin:3.1.0:clean -Dmaven.clean.failOnError=false

  • mvn --batch-mode org.jacoco:jacoco-maven-plugin:prepare-agent package

  • Maven wird auf Systemebene mit einer settings.xml-Datei konfiguriert, die automatisch das öffentliche Adobe-Artefakt-Repository enthält und ein Profil namens adobe-public verwendet. (Weitere Informationen dazu finden Sie im Adobe Public Maven Repository).

HINWEIS

Obwohl Cloud Manager keine bestimmte Version des Programms des jacoco-maven-plugin definiert, muss mindestens die Version 0.7.5.201505241946 verwendet werden.

Verwenden einer bestimmten Java-Version

Standardmäßig werden Projekte vom Cloud Manager-Build-Prozess mit dem Oracle 8 JDK erstellt. Kunden, die ein alternatives JDK verwenden möchten, haben zwei Optionen.

Maven Toolchains

Das Maven Toolchain-Plug-in ermöglicht es Projekten, ein bestimmtes JDK (oder Toolchain) auszuwählen, das im Kontext von Toolchain-fähigen Maven-Plug-ins verwendet werden soll. Dies geschieht in der pom.xml-Datei des Projekts, indem ein Anbieter und ein Versionswert angegeben werden.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-toolchains-plugin</artifactId>
    <version>1.1</version>
    <executions>
        <execution>
            <goals>
                <goal>toolchain</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <toolchains>
            <jdk>
                <version>11</version>
                <vendor>oracle</vendor>
            </jdk>
        </toolchains>
    </configuration>
</plugin>

Dies führt dazu, dass alle Toolchain-fähigen Maven-Plug-ins das Oracle JDK, Version 11 verwenden.

Bei Verwendung dieser Methode wird Maven selbst weiterhin mit dem standardmäßigen JDK (Oracle 8) ausgeführt und die JAVA_HOME-Umgebungsvariable wird nicht geändert. Daher funktioniert das Überprüfen oder Erzwingen der Java-Version über Plug-ins wie das Apache Maven Enforcer-Plug-in nicht und solche Plug-ins dürfen nicht verwendet werden.

Die derzeit verfügbaren Anbieter-/Versionskombinationen sind:

Anbieter Version
oracle 1.8
oracle 1.11
oracle 11
sun 1.8
sun 1.11
sun 11
HINWEIS

Ab April 2022 wird Oracle JDK das Standard-JDK für die Entwicklung und den Betrieb von AEM-Programmen sein. Der Build-Prozess von Cloud Manager wechselt automatisch zur Verwendung von Oracle JDK, auch wenn in der Maven-Toolchain explizit eine alternative Option ausgewählt ist. Weitere Informationen finden Sie in den Versionshinweisen vom April, sobald sie veröffentlicht werden.

Version des alternativen Maven-Ausführungs-JDK

Es ist auch möglich, Java 8 oder Java 11 als JDK für die gesamte Maven-Ausführung auszuwählen. Im Gegensatz zu den Toolchain-Optionen ändert dies das für alle Plug-ins verwendete JDK, es sei denn, die Toolchain-Konfiguration ist ebenfalls festgelegt. In diesem Fall wird die Toolchain-Konfiguration weiterhin für Toolchain-fähige Maven-Plug-ins angewendet. Daher funktioniert in diesem Fall das Überprüfen und Erzwingen der Java-Version mit dem Apache Maven Enforcer-Plug-in.

Erstellen Sie dazu eine Datei mit dem Namen .cloudmanager/java-version in der von der Pipeline verwendeten Git-Repository-Verzweigung. Diese Datei kann entweder den Inhalt 11 oder 8 enthalten. Alle anderen Werte werden ignoriert. Wenn 11 angegeben ist, wird Oracle 11 verwendet und die Variable JAVA_HOME Umgebungsvariable auf /usr/lib/jvm/jdk-11.0.2. Wenn 8 angegeben ist, wird Oracle 8 verwendet und die Variable JAVA_HOME Umgebungsvariable auf /usr/lib/jvm/jdk1.8.0_202.

Umgebungsvariablen

Standard-Umgebungsvariablen

Je nach den Informationen über das Programm oder die Pipeline kann es notwendig sein, den Build-Prozess zu variieren.

Wenn beispielsweise eine JavaScript-Minimierung während der Build-Erstellung mithilfe eines Tools wie gulp durchgeführt wird, soll beim Erstellen für eine Entwicklungsumgebung möglicherweise eine andere Minimierungsstufe verwendet werden als beim Erstellen für eine Staging- oder Produktionsumgebung.

Um dies zu unterstützen, fügt Cloud Manager diese Standard-Umgebungsvariablen bei jeder Ausführung dem Build-Container hinzu.

Variablenname Definition
CM_BUILD Immer auf true (wahr) festgelegt
BRANCH Die konfigurierte Verzweigung für die Ausführung
CM_PIPELINE_ID Numerische Pipeline-Kennung
CM_PIPELINE_NAME Name der Pipeline
CM_PROGRAM_ID Numerische Programmkennung
CM_PROGRAM_NAME Name des Programms
ARTIFACTS_VERSION Die von Cloud Manager generierte synthetische Version bei einer Staging- oder Produktions-Pipeline
CM_AEM_PRODUCT_VERSION Die Release-Version

Pipeline-Variablen

Der Build-Prozess kann von bestimmten Konfigurationsvariablen abhängen, die nicht im Git-Repository platziert werden können oder zwischen Pipeline-Ausführungen mit derselben Verzweigung variieren müssen.

Cloud Manager ermöglicht die Konfiguration dieser Variablen über die Cloud Manager-API oder die Cloud Manager-CLI individuell für die Pipelines. Variablen können entweder als reiner Test oder mit Data-at-Rest-Verschlüsselung gespeichert werden. In beiden Fällen werden Variablen innerhalb der Build-Umgebung als Umgebungsvariable bereitgestellt, die in der pom.xml-Datei oder anderen Build-Skripten referenziert werden kann.

Dieser CLI-Befehl legt eine Variable fest.

$ aio cloudmanager:set-pipeline-variables PIPELINEID --variable MY_CUSTOM_VARIABLE test

Dieser Befehl listet Variablen auf.

$ aio cloudmanager:list-pipeline-variables PIPELINEID

Variablennamen müssen die folgenden Konventionen einhalten.

  • Variablen dürfen nur alphanumerische Zeichen und den Unterstrich (_) enthalten.
  • Die Namen sollten in Großbuchstaben geschrieben sein.
  • Pro Pipeline sind maximal 200 Variablen zulässig.
  • Jeder Name darf höchstens 99 Zeichen enthalten.
  • Jede string-Variable darf höchstens 2047 Zeichen enthalten.
  • Jede Variable vom Typ secretString darf höchstens 499 Zeichen enthalten.

Bei Verwendung in einer Maven-pom.xml-Datei ist es in der Regel hilfreich, diese Variablen Maven-Eigenschaften mithilfe einer ähnlichen Syntax wie dieser zuzuordnen.

        <profile>
            <id>cmBuild</id>
            <activation>
                <property>
                    <name>env.CM_BUILD</name>
                </property>
            </activation>
            <properties>
                <my.custom.property>${env.MY_CUSTOM_VARIABLE}</my.custom.property>
            </properties>
        </profile>

Installieren zusätzlicher Systempakete

Einige Builds erfordern die Installation zusätzlicher Systempakete, damit sie vollumfänglich funktionieren. So ist es z. B. möglich, dass ein Build ein Python- oder Ruby-Skript aufruft, wofür der entsprechende Sprach-Interpreter installiert sein muss. Dies kann durch Aufrufen des exec-maven-plugin in ihrer pom.xml erfolgen, wodurch APT aufgerufen wird. Diese Ausführung sollte im Allgemeinen in einem Cloud Manager-spezifischen Maven-Profil eingeschlossen sein. In diesem Beispiel wird Python installiert.

        <profile>
            <id>install-python</id>
            <activation>
                <property>
                        <name>env.CM_BUILD</name>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>exec-maven-plugin</artifactId>
                        <version>1.6.0</version>
                        <executions>
                            <execution>
                                <id>apt-get-update</id>
                                <phase>validate</phase>
                                <goals>
                                    <goal>exec</goal>
                                </goals>
                                <configuration>
                                    <executable>apt-get</executable>
                                    <arguments>
                                        <argument>update</argument>
                                    </arguments>
                                </configuration>
                            </execution>
                            <execution>
                                <id>install-python</id>
                                <phase>validate</phase>
                                <goals>
                                    <goal>exec</goal>
                                </goals>
                                <configuration>
                                    <executable>apt-get</executable>
                                    <arguments>
                                        <argument>install</argument>
                                        <argument>-y</argument>
                                        <argument>--no-install-recommends</argument>
                                        <argument>python</argument>
                                    </arguments>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

Mit derselben Methode können Sie auch sprachspezifische Pakete installieren, d. h. mit gem für RubyGems oder mit pip für Python-Pakete.

HINWEIS

Wenn Sie ein Systempaket auf diese Weise installieren, wird es nicht in der Laufzeitumgebung installiert, die für die Ausführung von Adobe Experience Manager verwendet wird. Wenn Sie ein Systempaket in der AEM-Umgebung installieren möchten, wenden Sie sich an Ihre Adobe-Support-Mitarbeiter.

Auf dieser Seite