Uppdateringar av AEM aem-version-updates

Läs om hur Adobe Experience Manager (AEM) as a Cloud Service använder kontinuerlig integrering och leverans (CI/CD) för att hålla dina projekt uppdaterade med den senaste versionen.

CI/CD ci-cd

AEM as a Cloud Service använder kontinuerlig integrering och kontinuerlig leverans (CI/CD) för att säkerställa att dina projekt har den senaste AEM versionen. Den här processen uppdaterar dina produktions-, staging- och utvecklingsinstanser utan att störa användarna.

Innan instanserna uppdateras automatiskt kommer en ny AEM att publiceras 3-5 dagar i förväg. Under den här perioden kan din utvecklingsinstans uppdateras automatiskt eller om den är tillgänglig kan du välja att utlösa uppdateringen för dina utvecklingsinstanser. Versionsuppdateringar tillämpas automatiskt i dina utvecklingsmiljöer först. Om uppdateringen lyckas fortsätter den till din scen och dina produktionsinstanser. Utvecklings- och staging-instanserna fungerar som en automatiserad kvalitetsport, där dina anpassade tester körs innan uppdateringen tillämpas i produktionsmiljön.

NIMU (Non-Intrusive Maintenance Updates) nimu

Icke-påträngande underhållsuppdateringar är automatiska uppdateringar som tillämpas utan att kundens rörledningar används.
Med NIMU kan kunden använda pipeline när som helst, även om en AEM version är planerad eller pågår och underhållsuppdateringar inte längre visas i kundens pipeline-körningshistorik, vilket gör det enklare att följa historiken för koddistributioner.

Uppdatera aktiviteter

Den aktuella AEM-versionen kan fortfarande kontrolleras för varje miljö, som tidigare, med hjälp av Cloud Manager UI-miljöpanel. Samma kvalitetsgater som används i pipeline används av icke-intrångsrelaterade underhållsuppdateringar, inklusive kundens skriftliga tester.
Ett Cloud Manager UI-meddelande skickas varje gång en icke-påträngande underhållsuppdatering används i programmets miljöer. Du kan konfigurera det så att det även skickas till ditt e-postmeddelande.

Typ av uppdateringar update-types

Det finns två typer AEM versionsuppdateringar:

Uppdateringsfel update-failure

AEM uppdateringar genomgår en intensiv och helt automatiserad produktvalideringsplan som omfattar flera steg, vilket säkerställer att ingen tjänst avbryts för system i produktionen. Hälsokontroller används för att övervaka programmets hälsa. Om dessa kontroller misslyckas under en AEM as a Cloud Service-uppdatering fortsätter inte releasen och Adobe undersöker varför uppdateringen orsakade detta oväntade beteende.

När du distribuerar en ny version av anpassad kod i din miljö spelar Funktionstester för produkter och anpassadeen viktig roll. De säkerställer att produktionssystemen förblir stabila och fungerar även efter det att en ändring har gjorts. De här testerna används också i AEM.

Om uppdateringen till produktionsmiljön misslyckas, kommer Cloud Manager automatiskt att återställa testmiljön. Detta görs automatiskt för att säkerställa att både testnings- och produktionsmiljöerna finns i samma AEM när uppdateringen är klar.
Om en automatisk uppdatering av en utvecklingsmiljö misslyckas uppdateras inte heller mellanlagrings- och produktionsmiljöer.

Bästa praxis best-practices

Regression regression

Om du råkar ut för ett problem som rör regression ska du skicka in ett supportärende via Admin Console. Om problemet är ett blockeringsprogram och påverkar produktionen bör ett P1-fel tas upp. Ange alla detaljer som krävs för att återskapa regressionsproblemet.

Sammansatt nodarkiv composite-node-store

Vanligtvis har uppdateringarna inga driftavbrott, inklusive för redigeringsinstansen, som är ett kluster med noder. Rullande uppdateringar är möjliga på grund av funktionen för lagring av sammansatta noder i Oak.

Med den här funktionen kan AEM referera till flera databaser samtidigt. I en rullande distribution innehåller den nya AEM en egen /libs (den TjärMK-baserade oföränderliga databasen). Den skiljer sig från den äldre AEM versionen, även om båda refererar till en delad DocumentMK-baserad ändringsbar databas som innehåller områden som /content, /conf och /etc med flera.

Eftersom både den gamla och den nya versionen har egna versioner av /libs kan båda vara aktiva under den rullande uppdateringen. Och båda kan ta trafik tills den gamla är helt ersatt av den nya.

Ytterligare information further-information

Mer information om relaterade teman: