Uw project instellen setting-up-your-project

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

Bestaande projecten bewerken modifying-project-setup-details

Bestaande AEM Projecten moeten zich aan sommige basisregels houden zodat zij met succes met Cloud Manager kunnen worden gebouwd en worden opgesteld.

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 milieuvariabelete 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 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 het volgende 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 Maven-opslagruimte met wachtwoord password-protected-maven-repositories

Artefacten van een met een wachtwoord beveiligde Maven-opslagplaats moeten voorzichtig worden gebruikt, omdat code die op deze manier wordt geïmplementeerd, niet volledig wordt onderworpen aan de kwaliteitscontroles die door Cloud Manager worden uitgevoerd. De Adobe adviseert ook dat u ook de bronnen van Java en de volledige projectbroncode samen met binair getal opstelt.

Om een wachtwoord-beschermde Gemaakt 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 bewaarplaats van het Git. Dit dossier volgt het 🔗 schema van het Dossier van Montages 0} Maven.

Wanneer het Cloud Manager-constructieproces start, wordt het element <servers> in dit bestand samengevoegd met het standaardbestand van settings.xml dat door Cloud Manager wordt geleverd. Aangepaste servers mogen geen server-id's gebruiken die beginnen met adobe en cloud-manager . Dergelijke id's worden als gereserveerd beschouwd. Cloud Manager spiegelt alleen de server-id's die overeenkomen met een van de opgegeven voorvoegsels of de standaard-id central .

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 dat de gegevensopslagruimte zich op https://repository.myco.com/maven2 bevindt, de gebruikersnaam die Cloud Manager moet gebruiken, is cloudmanager en het wachtwoord is secretword .

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 het volgende:

<?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 goede praktijken om de volledige projectbron samen met binair aan een Geweven bewaarplaats op te stellen. Zo 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 overslaan skipping-content-packages

In Cloud Manager kunnen builds een willekeurig aantal inhoudspakketten produceren. Om diverse redenen is het misschien gewenst om een inhoudspakket te maken, maar dit niet te implementeren. Deze benadering kan bijvoorbeeld handig zijn wanneer u inhoudspakketten maakt die alleen voor testen bestemd zijn of wanneer een andere stap in het constructieproces deze pakketten opnieuw verpakt. Dat wil zeggen, als 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 dit bezit te plaatsen hangt van de manier af de bouwstijl het inhoudspakket produceert. Met de filevault-maven-plugin configureert u de plug-in bijvoorbeeld 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>

Hergebruik van artefact maken build-artifact-reuse

In veel gevallen, wordt de zelfde code opgesteld aan veelvoudige AEM milieu's. Waar mogelijk, vermijdt Cloud Manager het herbouwen van de codebasis wanneer het ontdekt dat het zelfde Git 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 door middel van 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 maakt een lijst van de artefacten en de uitvoeringsinformatie 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 bevat gelijkaardige informatie.

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: Vertakking foo en Vertakking bar .

Beide vertakkingen hebben zelfde verbind identiteitskaart

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

Weigeren 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, begaat hash nog wordt gehaald. De resulterende artefacten worden opgeslagen voor later gebruik, maar eerder opgeslagen artefacten worden niet opnieuw gebruikt. Overweeg het volgende scenario om dit gedrag te begrijpen:

Caveats caveats

Ontwikkelen van uw code op basis van best practices develop-your-code-based-on-best-practices

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