Lägg till en icke-produktionspipeline configuring-non-production-pipelines
När du har konfigurerat ett program och skapat minst en miljö i användargränssnittet i Cloud Manager kan du lägga till rörledningar som inte är avsedda för produktion. Med dessa rörledningar kan du testa kodkvaliteten innan du distribuerar den till produktionsmiljöer.
En användare måste ha rollen Distributionshanteraren för att kunna konfigurera icke-produktionspipelines.
Lägg till en ny icke-produktionspipeline adding-non-production-pipeline
När du har konfigurerat ett program och skapat minst en miljö i användargränssnittet i Cloud Manager kan du lägga till rörledningar som inte är avsedda för produktion. Använd dessa rörledningar för att testa kodkvaliteten innan du distribuerar till produktionsmiljöer.
Så här lägger du till en ny icke-produktionsflöde:
-
Logga in på Cloud Manager på experience.adobe.com.
-
Klicka på Experience Manager i avsnittet Snabbåtkomst.
-
Klicka på Cloud Manager på den vänstra panelen.
-
Välj en organisation som du vill ha.
-
Klicka på ett program på konsolen Mina program.
-
Klicka på Rörledningar på den vänstra panelen.
-
Klicka på Lägg till pipeline > Lägg till icke-produktionsförlopp på sidan Förgreningar, nära det övre högra hörnet.
-
På fliken Konfiguration i dialogrutan Lägg till icke-produktionsförlopp väljer du någon av följande icke-produktionsförloppsrör som du vill skapa:
- Kodkvalitetspipeline - Skapar en pipeline som bygger koden på en GIT-gren, kör enhetstester och utvärderar kodkvaliteten utan att distribuera den till någon miljö.
- Distributionspipeline - Skapar en pipeline som bygger koden, kör enhetstester, utvärderar kodkvaliteten och distribuerar till en icke-produktionsmiljö.
-
Under avsnittet Pipelinekonfiguration skriver du en beskrivning för din icke-produktionspipeline i fältet Namn på icke-produktionspipeline.
-
Under avsnittet Distributionsalternativ väljer du en av följande distributionsutlösare som du vill använda:
- Manuell - Du kan starta pipelinen manuellt.
- Vid Git-ändringar - Startar pipelinen när implementeringar läggs till i den konfigurerade Git-grenen. Med det här alternativet kan du fortfarande starta pipelinen manuellt efter behov.
-
Välj det viktiga måttfel som du vill använda.
- Fråga varje gång - Det här beteendet är standardinställningen och kräver manuell åtgärd vid viktiga fel.
- Misslyckades omedelbart - Om du väljer det här alternativet avbryts pipelinen när ett viktigt fel inträffar. Det emulerar i stort sett en användare som manuellt avvisar varje fel.
- Fortsätt omedelbart - Om du väljer det här alternativet fortsätter pipeline automatiskt när ett viktigt fel inträffar. Det emulerar i stort sett en användare som manuellt godkänner varje fel.
-
Klicka på Fortsätt.
-
De återstående stegen som du använder för att slutföra konfigurationen av produktionsflödet beror på vilken typ av källkod du väljer att använda.
På fliken Source Code i dialogrutan Add Non-Production Pipeline väljer du vilken typ av kod som icke-produktionsflödet ska bearbeta.Mer information om olika typer av pipelines finns i CI/CD Pipelines.
Jag använder fullständig stackkod full-stack-code
En fullständig kodrapport distribuerar samtidigt kodbyggen i bakände och framände som innehåller en eller flera AEM-serverprogram tillsammans med HTTPD/Dispatcher-konfiguration.
Så här slutför du konfigurationen av icke-produktionsflödet för kod i helhög:
-
I avsnittet Source-kod definierar du följande alternativ.
-
Berättigade distributionsmiljöer - Endast tillgängligt när du redigerar en icke-produktionspipeline. Om din pipeline är en distributionsprocess måste du välja till vilka miljöer den ska distribueras.
-
Databas - I listrutan väljer du Git-databasen som pipeline använder som källa. Cloud Manager skapar kod från den databas du väljer här.
note tip TIP Se Lägga till och hantera databaser så att du kan lära dig hur du lägger till och hanterar databaser i Cloud Manager. -
Git-grenen - I listrutan väljer du vilken gren i den valda databasen som pipeline ska bygga från. Standardvärdet är
main. I pipeline används den valda grenen som källa för bygge och distribution. Om det behövs klickar du på Uppdatera för att uppdatera listan över tillgängliga grenar för den valda databasen. Använd det här alternativet om en nyligen skapad gren inte visas i listan. -
Skapa strategi
-
Fullständigt bygge - Bygger alla moduler i databasen varje gång
-
BETA Smart Build - Skapar endast moduler som har ändrats sedan den senaste implementeringen.
Lär dig mer om att använda Smart Build i en icke-produktionsprocess.note important IMPORTANT Smart Build är endast tillgängligt för pipelines för kodkvalitet och distributionspipelines för Dev Full Stack Code.
-
-
Kryssrutan Ignorera webbnivåkonfiguration - När det här alternativet är markerat distribueras inte webbnivåkonfigurationen.
-
-
Om din pipeline är en distributionspipeline i avsnittet Pipeline kan du välja att köra en testfas. Markera de alternativ som du vill aktivera i den här fasen. Om inget av alternativen är markerat visas inte testfasen när pipeline körs.
- Funktionstestning av produkt - Kör produktfunktionstester mot utvecklingsmiljön.
- Anpassad funktionstestning - Kör anpassade funktionstester mot utvecklingsmiljön.
- Anpassad gränssnittstestning - Kör anpassade gränssnittstester för anpassade program.
- Experience Audit - Kör Experience Audit
-
Klicka på Spara.
Pipelinen sparas och du kan nu [hantera dina pipelines](hantera pipe)
lines.md) på kortet Pipelines på sidan Programöversikt .
Jag använder målinriktad distribution targeted-deployment
En riktad distribution distribuerar kod endast för utvalda delar av AEM-programmet. I en sådan distribution kan du välja att Inkludera ska vara en av följande typer av kod:
-
Front End Code - Konfigurera JavaScript och CSS för frontdelen av ditt AEM-program.
- Med rörledningar kan utvecklarna bli mer självständiga och utvecklingsprocessen kan accelereras.
- I dokumentet Utveckla platser med frontdelspipeline finns information om hur den här processen fungerar tillsammans med vissa överväganden som du bör vara medveten om för att få ut mesta möjliga av processen.
-
Webbnivåkonfiguration - Konfigurera Dispatcher-egenskaper för att lagra, bearbeta och leverera webbsidor till klienten.
-
Mer information finns i dokumentet CI/CD Pipelines.
-
Om det finns en kodrapport på webbnivå för den valda miljön är det här valet inaktiverat.
-
Om en pipeline med hela stackar redan distribueras till en miljö kan du fortfarande skapa en konfigurationspipeline på webbnivå för samma miljö. När du gör det ignorerar Cloud Manager webskiktskonfigurationen i pipeline för hela stacken.
note note NOTE Rörledningar för webbnivå och konfiguration stöds inte i privata databaser. Mer information och en fullständig lista över begränsningar finns i Lägga till privata databaser i Cloud Manager.
-
-
Ange följande alternativ under avsnittet Source-kod:
-
Databas - Det här alternativet definierar från vilken GIT-databas som icke-produktionsflödet ska hämta koden.
note tip TIP Se Lägga till och hantera databaser så att du kan lära dig hur du lägger till och hanterar databaser i Cloud Manager. -
Git-grenen - Det här alternativet definierar från vilken gren i den valda pipeline som ska hämta koden. Ange de första tecknen i förgreningsnamnet och funktionen Komplettera automatiskt i det här fältet. Här hittas de matchande grenar som du kan välja.
-
Kodplats - Det här alternativet definierar sökvägen i grenen för den valda rapporten från vilken pipelinen ska hämta koden.
-
-
Om du har aktiverat Experience Audit klickar du på Continue för att gå vidare till fliken Experience Audit där du kan definiera sökvägarna som alltid ska inkluderas i Experience Audit.
- Om du har aktiverat Experience Audit finns mer information om hur du konfigurerar i dokumentet Experience Audit.
- Om du inte gjorde det hoppar du över det här steget.
-
Klicka på Spara för att spara pipeline.
Pipelinen sparas och du kan nu hantera dina pipelines på kortet Pipelines på sidan Programöversikt.
Om att använda Smart Build i en icke-produktionsprocess about-smart-build-non-production-pipeline
Smart Build i Cloud Manager är en optimerad byggstrategi för icke-produktionspipelines. Smart Build minskar byggtiden genom att cache-lagra moduler och återskapa endast de moduler som har ändrats sedan den senaste körningen. Oförändrade moduler återanvänds från cacheminnet, medan endast ändrade moduler och deras beroenden återskapas, vilket förbättrar effektiviteten för iterativa utvecklingsarbetsflöden.
Smart Build är för närvarande endast tillgängligt för följande:
- Kodkvalitetsledningar.
- Utveckla rörledningar för driftsättning i högklasser.
Smart Build rekommenderas när du har följande:
- Du utvecklar och implementerar ofta inkrementella förändringar.
- Ditt projekt innehåller flera Maven-moduler.
- Fullversioner tar lång tid.
Smart Build är inte alltid idealiskt när du har följande:
- Din version är starkt beroende av plugin-program som utför åtgärder utanför Maven beroendediagram.
- Du måste verifiera alla versioner av varje körning.
Förstå byggprestanda smart-build-performance
Den prestandaökning som kan uppnås med Smart Build beror på flera faktorer, bland annat följande:
- Antalet moduler i projektet.
- Kodändringarnas frekvens och omfattning.
- Distributionen av beroenden mellan moduler.
I allmänhet kan projekt med många oberoende moduler se den största förbättringen.
Cacheavanmälan per modul smart-build-cache-optout
Smart Build har finkornig kontroll som gör att du kan inaktivera cachelagring för specifika moduler. Den här funktionen är användbar när vissa moduler:
- Använd plugin-program som
exec-maven-pluginellermaven-antrun-plugin. - Utför filåtgärder som inte spåras av Maven-beroenden.
- Cachelagrat innehåll ger inkonsekventa resultat.
Inaktivera cachelagring för en modul smart-build-disable-caching
Du kan lägga till följande egenskap i den berörda modulens pom.xml:
<properties>
<maven.build.cache.enabled>false</maven.build.cache.enabled>
</properties>
Den här syntaxen tvingar modulen att återskapa varje pipeline-körning medan andra moduler fortfarande har nytta av cachelagring.
Begränsningar och överväganden när Smart Build används smart-build-limitations
Tänk på följande när du använder Smart Build:
- Smart Build bygger på Maven-beroendeanalys.
- Ändringar utanför beroendediagrammet kan inte utlösa rekonstruktioner.
- Vissa plugin-program kanske inte är helt kompatibla med cachning.
- Du kan när som helst växla tillbaka till Fullständigt bygge genom att redigera icke-produktionsflödet.
Om du stöter på oväntat byggbeteende bör du inaktivera cachelagring för specifika moduler eller tillfälligt byta din byggstrategi till Fullständigt bygge.
Felsöka problem med Smart Build smart-build-troubleshoot
・ Verifiera plugin-programmets beteende (särskilt
exec/antrun plugin-program).・ Kontrollera om de flesta moduler ändras ofta.
・ Använd Fullständigt bygge för verifiering.
Se Lägg till en icke-produktionspipeline för att aktivera Smart Build.
Uteslut Dispatcher-paket exclude-dispatcher-packages
Om du vill att Dispatcher-paket ska byggas in i din pipeline men inte överföras för att bygga lagring inaktiverar du publicering. Om du gör det kan det korta körtiden.
Lägg till följande konfiguration i projektfilen pom.xml om du vill inaktivera publicering av Dispatcher-paket. Ange en miljövariabel i Cloud Manager byggbehållare för att flagga när Dispatcher-paket ska ignoreras. Pipelinen läser den här flaggan och ignorerar dem därefter.
<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>