Projectinstelling setting-up-your-project

Leer hoe u uw project instelt zodat u het kunt beheren en implementeren met Cloud Manager.

Bestaande projecten wijzigen modifying-project-setup-details

Bestaande AEM projecten moeten zich aan enkele basisregels houden om met succes met Cloud Manager te kunnen worden gebouwd en geïmplementeerd.

Geweven profielen activeren in Cloud Manager activating-maven-profiles-in-cloud-manager

In sommige beperkte gevallen, kunt u uw bouwstijlproces lichtjes moeten variëren wanneer het binnen Cloud Manager loopt in tegenstelling tot wanneer het op ontwikkelaarwerkstations loopt. Voor deze gevallen, Gemaakt Profielenkunnen worden gebruikt om te bepalen hoe de bouwstijl in verschillende milieu's, met inbegrip van Cloud Manager verschillend zou moeten zijn.

De activering van een Geweven Profiel binnen Cloud Manager bouwt milieu zou moeten worden gedaan door CM_BUILD milieu veranderlijkeomgevingsvariabele te zoeken. Omgekeerd moet een profiel dat alleen buiten de Cloud Manager-ontwikkelomgeving moet worden gebruikt, worden uitgevoerd door te zoeken naar de afwezigheid van deze variabele.

Als u bijvoorbeeld alleen een eenvoudig bericht wilt uitvoeren wanneer de build in Cloud Manager wordt uitgevoerd, doet u het volgende:

        <profile>
            <id>cmBuild</id>
            <activation>
                  <property>
                        <name>env.CM_BUILD</name>
                  </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.8</version>
                        <executions>
                            <execution>
                                <phase>initialize</phase>
                                <configuration>
                                    <target>
                                        <echo>I'm running inside Cloud Manager!</echo>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

En als u een eenvoudig bericht wilde uitvoeren slechts wanneer de bouwstijl buiten Cloud Manager in werking wordt gesteld, zou u dit doen:

        <profile>
            <id>notCMBuild</id>
            <activation>
                  <property>
                        <name>!env.CM_BUILD</name>
                  </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.8</version>
                        <executions>
                            <execution>
                                <phase>initialize</phase>
                                <configuration>
                                    <target>
                                        <echo>I'm running outside Cloud Manager!</echo>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

Ondersteuning voor met wachtwoord beveiligde gegevensopslagruimte password-protected-maven-repositories

Artefacten van een met een wachtwoord beveiligde Maven-opslagplaats mogen alleen zeer voorzichtig worden gebruikt, aangezien code die via dit mechanisme wordt geïmplementeerd, niet door alle kwaliteitsregels wordt uitgevoerd die in Cloud Manager worden geïmplementeerd. Het wordt geadviseerd om de bronnen van Java evenals de volledige code van de projectbron samen met het binaire getal op te stellen.

Om een wachtwoord-beschermde Gegeven bewaarplaats van Cloud Manager te gebruiken, specificeer het wachtwoord (en naar keuze, de gebruikersbenaming) als geheime Variabele van de Pijpleidingen verwijs dan dat geheim binnen een dossier genoemd .cloudmanager/maven/settings.xml in de git bewaarplaats. Dit dossier volgt het 🔗 schema van het Dossier van Montages 0} Maven.

Wanneer het Cloud Manager-constructieproces start, wordt het <servers> -element in dit bestand samengevoegd met het settings.xml -standaardbestand dat door Cloud Manager wordt geleverd. Server-id's die beginnen met adobe en cloud-manager worden beschouwd als gereserveerd en mogen niet worden gebruikt door aangepaste servers. Server-id's die niet overeenkomen met een van deze voorvoegsels of de standaard-id central worden nooit weerspiegeld door Cloud Manager.

Als dit bestand is geïnstalleerd, wordt vanuit een element <repository> en/of <pluginRepository> in het bestand pom.xml naar de server-id verwezen. Over het algemeen, zouden deze <repository> en/of <pluginRepository> elementen binnen a Cloud Manager-specifiek profielbevat zijn, hoewel dat niet strikt noodzakelijk is.

Stel bijvoorbeeld dat de repository zich op https://repository.myco.com/maven2 bevindt, dat de gebruikersnaam die Cloud Manager moet gebruiken cloudmanager is en dat het wachtwoord secretword is.

Plaats eerst het wachtwoord als geheim op de pijpleiding:

$ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword

Verwijs vervolgens vanuit het .cloudmanager/maven/settings.xml -bestand naar dit bestand:

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
        <server>
            <id>myco-repository</id>
            <username>cloudmanager</username>
            <password>${env.CUSTOM_MYCO_REPOSITORY_PASSWORD}</password>
        </server>
    </servers>
</settings>

En ten slotte verwijs naar de server-id in het pom.xml -bestand:

<profiles>
    <profile>
        <id>cmBuild</id>
        <activation>
                <property>
                    <name>env.CM_BUILD</name>
                </property>
        </activation>
        <build>
            <repositories>
                <repository>
                    <id>myco-repository</id>
                    <name>MyCo Releases</name>
                    <url>https://repository.myco.com/maven2</url>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                </repository>
            </repositories>
            <pluginRepositories>
                <pluginRepository>
                    <id>myco-repository</id>
                    <name>MyCo Releases</name>
                    <url>https://repository.myco.com/maven2</url>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                </pluginRepository>
            </pluginRepositories>
        </build>
    </profile>
</profiles>

Bronnen implementeren deploying-sources

Het is een goede praktijk om de bronnen van Java samen met binair aan een Geweven bewaarplaats op te stellen.

Configureer de maven-source-plugin in uw project:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <executions>
                <execution>
                    <id>attach-sources</id>
                    <goals>
                        <goal>jar-no-fork</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

Projectbronnen implementeren deploying-project-sources

Het is een goede praktijk om de volledige projectbron samen met binair aan een Geweven bewaarplaats op te stellen. Hierdoor kan het exacte artefact worden hersteld.

Configureer de maven-assembly-plugin in uw project:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <executions>
                <execution>
                    <id>project-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                    <configuration>
                        <descriptorRefs>
                            <descriptorRef>project</descriptorRef>
                        </descriptorRefs>
                    </configuration>
                </execution>
            </executions>
        </plugin>

Inhoudspakketten worden overgeslagen skipping-content-packages

In Cloud Manager kunnen builds een willekeurig aantal inhoudspakketten produceren. Om diverse redenen kan het wenselijk zijn een inhoudspakket te maken, maar het niet te implementeren. Dit kan bijvoorbeeld handig zijn wanneer u inhoudspakketten maakt die alleen voor testen worden gebruikt of die door een andere stap in het constructieproces opnieuw worden verpakt, dat wil zeggen als een subpakket van een ander pakket.

Cloud Manager zoekt naar een eigenschap met de naam cloudManagerTarget in de eigenschappen van samengestelde inhoudspakketten om deze scenario's te kunnen gebruiken. Als deze eigenschap is ingesteld op none , wordt het pakket overgeslagen en niet geïmplementeerd. Het mechanisme om deze eigenschap in te stellen hangt af van de manier waarop de build het contentpakket produceert. Met de filevault-maven-plugin configureert u bijvoorbeeld de insteekmodule als volgt:

        <plugin>
            <groupId>org.apache.jackrabbit</groupId>
            <artifactId>filevault-package-maven-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <properties>
                    <cloudManagerTarget>none</cloudManagerTarget>
                </properties>
        <!-- other configuration -->
            </configuration>
        </plugin>

Met de lus content-package-maven-plugin is deze vergelijkbaar:

        <plugin>
            <groupId>com.day.jcr.vault</groupId>
            <artifactId>content-package-maven-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <properties>
                    <cloudManagerTarget>none</cloudManagerTarget>
                </properties>
        <!-- other configuration -->
            </configuration>
        </plugin>

Artefacthergebruik maken build-artifact-reuse

In veel gevallen, wordt de zelfde code opgesteld aan veelvoudige AEM milieu's. Waar mogelijk, zal Cloud Manager vermijden herbouwend de codebasis wanneer het ontdekt dat het zelfde gat begaan wordt gebruikt in veelvoudige full-stack pijpleidinguitvoeringen.

Wanneer een uitvoering is begonnen, begaat de huidige HEAD voor de takpijpleiding wordt gehaald. De commit hash is zichtbaar in UI en via API. Wanneer de bouwstijlstap met succes voltooit, worden de resulterende artefacten opgeslagen gebaseerd op die knoeiboel begaan en kunnen in verdere pijpleidingsuitvoeringen opnieuw worden gebruikt.

Pakketten worden opnieuw gebruikt via pijpleidingen als ze zich in hetzelfde programma bevinden. Wanneer u pakketten zoekt die opnieuw kunnen worden gebruikt, negeert AEM vertakkingen en hergebruikt artefacten tussen vertakkingen.

Wanneer een hergebruik voorkomt, worden de bouw en de stappen van de codekwaliteit effectief vervangen met de resultaten van de originele uitvoering. Het logboekdossier voor de bouwstijlstap zal van de artefacten en de uitvoeringsinformatie een lijst maken die werd gebruikt om hen oorspronkelijk te bouwen.

Hieronder ziet u een voorbeeld van een dergelijke loguitvoer.

The following build artifacts were reused from the prior execution 4 of pipeline 1 which used commit f6ac5e6943ba8bce8804086241ba28bd94909aef:
build/aem-guides-wknd.all-2021.1216.1101633.0000884042.zip (content-package)
build/aem-guides-wknd.dispatcher.cloud-2021.1216.1101633.0000884042.zip (dispatcher-configuration)

Het logboek van de stap van de codekwaliteit zal gelijkaardige informatie bevatten.

Voorbeelden example-reuse

Voorbeeld 1 example-1

Houd er rekening mee dat uw programma twee ontwikkelingspijplijnen heeft:

Beide vertakkingen zijn op zelfde verbind identiteitskaart

Voorbeeld 2 example-2

Houd er rekening mee dat uw programma twee vertakkingen heeft:

Beide vertakkingen hebben zelfde verbind identiteitskaart

In dit geval wordt het artefact van foo opnieuw gebruikt voor de productiepijplijn aangezien dezelfde commit hash werd geïdentificeerd.

Afmelden opting-out

Indien gewenst, kan het hergebruikgedrag voor specifieke pijpleidingen worden onbruikbaar gemaakt door de pijpleidingsvariabele CM_DISABLE_BUILD_REUSE aan true te plaatsen. Als deze variabele wordt geplaatst, begaan hash nog wordt gehaald en de resulterende artefacten voor later gebruik zullen worden opgeslagen, maar om het even welke eerder opgeslagen artefacten zullen niet opnieuw worden gebruikt. Overweeg het volgende scenario om dit gedrag te begrijpen.

Caveats caveats

Ontwikkel uw Code die op Beste praktijken wordt gebaseerd develop-your-code-based-on-best-practices

De Techniek van de Adobe en de Consulting teams hebben a uitvoerige reeks beste praktijken voor AEM ontwikkelaars ontwikkeld.