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.

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 finns i 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 göra det aktivera 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 miljöpanelen i användargränssnittet i Cloud Manager. Samma kvalitetsgater som används i pipeline används av icke-intrångsrelaterade underhållsuppdateringar, inklusive kundens skriftliga tester.
Ett meddelande om användargränssnittet i molnhanteraren skickas när en icke-intrångsrelaterad underhållsuppdatering tillämpas 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ö, Funktionstester för produkter och anpassade spela en 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, återställer Cloud Manager automatiskt 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 löpande driftsättning, 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, men båda refererar till en delad DocumentMK-baserad mutable-databas som innehåller områden som /content , /conf , /etc och andra.

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