Under kundens implementeringsfas kommer du att utforska de verktyg du kan använda för att göra koden och innehållet redo att flyttas över till AEM as a Cloud Service.
I tidigare delar av resan har du gått igenom bekanta dig med förändringar i AEM as a Cloud Serviceoch avgör om distributionen är klar att flyttas till molnet med beredskapsfas.
Artikeln fortsätter med råd om hur du använder verktygen som tillhandahålls av Adobe för att se till att koden och innehållet är klara att flyttas till molnet.
Syftet med detta dokument är att
Innan du börjar måste du bekanta dig med Cloud Manager eftersom det är den enda metoden att distribuera kod till AEM as a Cloud Service.
Med Cloud Manager kan organisationer själva hantera AEM i molnet. Det innehåller ett ramverk för kontinuerlig integrering och kontinuerligt leverans (CI/CD) som gör att IT-team och implementeringspartners kan snabba upp leveransen av anpassningar eller uppdateringar utan att kompromissa med prestanda eller säkerhet.
Du kan bekanta dig med Cloud Manager genom att läsa resurserna nedan:
Onboardresa för att förstå självhjälpsresurser om hur man kommer igång på Experience Manager as a Cloud Service.
Integrera Git med Adobe Cloud Manager för att lära dig mer om hur du använder en enstaka Git-databas för att driftsätta kod.
Adobe Experience as a Cloud Service-konfiguration för att lära dig mer om hur du hanterar produkter och användaråtkomst i Admin Console.
Hur övergången till Cloud Service ser ut beror på vilka system du har köpt och vilka metoder du följer för programutveckling.
I följande bild visas de huvudsakliga stegen som ingår i fasen, som innefattar att konvertera kod och innehåll för användning med AEM as a Cloud Service:
Vi börjar med att gå igenom de verktyg du måste använda så att du kan göra det i kapitlen nedan.
Om du vill migrera innehåll från den aktuella AEM till Cloud Servicen kan du använda verktyget för innehållsöverföring i Adobe.
Med det här verktyget kan du ange önskad delmängd av innehållet som du vill överföra från din AEM-källinstans till din AEM Cloud Service-instans.
Innehållsmigrering är en flerstegsprocess som kräver planering, spårning och samarbete mellan olika team.
En fullständig beskrivning av hur verktyget fungerar och hur Adobe rekommenderar att du använder det finns i Dokumentation för verktyget Innehållsöverföring.
Det är dags att börja omfaktorisera de befintliga funktionerna så att de blir kompatibla med Cloud Service.
Börja med att titta på dokumentationen som beskriver de grundläggande verktygen och börja omfaktorisera koden:
Du kan också:
I den här videon får du veta hur du installerar Dispatcher SDK lokalt:
I den här videon ser du hur du konfigurerar Dispatcher SDK:
Att utveckla och köra kod i AEM as a Cloud Service kräver en förändring i sinnesen. Observera att koden måste vara flexibel, särskilt eftersom en instans kan avbrytas när som helst. Kod som körs i Cloud Service måste vara medveten om att den alltid körs i ett kluster. Det innebär att fler än en instans alltid körs.
Vissa ändringar krävs för att AEM Maven-projekt ska vara molnkompatibla. AEM as a Cloud Service kräver separation av innehåll och kod till olika paket för distribution till AEM:
/apps
och /libs
betraktas som oföränderliga AEM eftersom de inte kan ändras efter att AEM har startats (det vill säga vid körning). Detta inkluderar åtgärder för att skapa, uppdatera eller ta bort. Alla försök att ändra ett oföränderligt område vid körning misslyckas.
Allt annat i databasen (till exempel /content
, /conf
, /var
, /home
, /etc
, /oak:index
, /system
, /tmp
) är alla oföränderliga områden, vilket innebär att de kan ändras under körning.
Du kan lära dig mer genom att läsa Rekommenderad paketstruktur dokumentation.
I Adobe finns flera verktyg som hjälper dig att snabba upp vissa av dina åtgärder för kodomfaktorisering. Om du förstår dessa verktyg och de problem de löser blir migreringen mindre komplicerad och tidsödande.
När du väl har konfigurerat den lokala utvecklingsmiljön kan du bekanta dig med den AEM as a Cloud Service SDK:n genom att kontakta dokumentation.
För att kunna hantera kodutvecklingen på din aktiva AEM tillsammans med kodomfaktoriseringsuppgifterna som en del av din övergångsresa rekommenderar Adobe att du planerar en frysperiod tills du har slutfört omstruktureringen av ditt Maven-projekt så att det blir kompatibelt med AEM as a Cloud Service.
När projektomstruktureringen är klar kan du återuppta utvecklingen av ny kod baserat på den nya strukturen. Detta minskar antalet fel i molnhanterarens pipeline under koddistribution och testning.
Aktiviteterna Innehållsöverföring och Kodreaktorn behöver inte utföras sekventiellt. Dessa åtgärder kan utföras oberoende av varandra. Korrekt projektstruktur krävs dock för att innehållet ska återges korrekt i Cloud Service-miljön.
Molnhanterarens pipeline stöder körning av tester som körs mot scenmiljön.
Följ god praxis i dokumenten nedan när det gäller kvalitetstestning av kod:
När du förbereder källsystemet för migrering måste du utföra åtgärder på system- och AEM-nivå. Du kan börja med att verifiera att innehållsdatabasen är i ett väl underhållet tillstånd genom att kontrollera rensning av revision och skräpinsamling för datalager aktivitetsstatus. Om du kör AEM version 6.3 (eftersom verktyget Innehållsöverföring är kompatibelt från version 6.3 och framåt) bör du utföra offlinekomprimering följt av skräpinsamlingen i datalagret.
Konsekvenskontroll rekommenderas för alla AEM versioner för att säkerställa att innehållsarkivet är i ett bra läge för att starta migreringsaktiviteter.
Åtkomst på systemadministratörsnivå krävs för att installera och konfigurera AZCopy
Vi rekommenderar även att du granskar resurser, sidor, AEM projekt, användare och grupper som inte används för att spara tid när du migrerar. Se Hälsa för innehållsdatabas -avsnitt.
En gång för alla produktionsklona fastställs, fortsätta för att kontrollera databasens hälsa. Som nämndes i föregående avsnitt är målet att rensa och komprimera databasen på källan innan migreringen startar. Det här steget kan spara mycket tid i annat fall för felsökning när migreringen startar.
Åtgärdsobjekt | Viktiga uppgifter |
---|---|
Användare, grupper och behörigheter | Ni måste förstå hur många användare, grupper och komplex medlemskapet är. Leta efter möjligheter att rensa bort oanvända användare, grupper i källan före migrering. |
Ofullständig resursbearbetning | Försök att slutföra bearbetningen av resurser i källsystemet innan du påbörjar migreringen för att undvika potentiella problem AEM as a Cloud Service eftermigrering. |
Innehållshälsa | Vi rekommenderar att du frågar efter skadat innehåll och tömmer det innan du startar migreringen. Du kan till exempel söka efter resurser eller sidor som inte har ursprungliga återgivningar eller som fastnat i arbetsflödesbearbetningen. Se även Resurshälsa. |
The Strategi för innehållsmigrering och tidslinje mer ingående information om hur man extrapolerar insamlade data och skapar en migreringsplan.
Genom att samla in data kan du planera migreringsaktiviteterna och tillhörande uppgifter. Extraherings- och inmatningstiderna är särskilt användbara eftersom datapunkterna kan kopplas till en viss migreringsuppsättningens storlek. Därför kan dessa datapunkter extrapoleras för att ta fram en plan:
Dessa datapunkter kan även hjälpa dig Fastställa KPI:er och andra migreringsrelaterade uppgifter.
Baserat på de datapunkter du har samlat in (se ovan) kan du skapa en migreringsplan som kan integreras i en makroprojektplan. Detta steg kommer att göra det möjligt för alla viktiga intressenter att visualisera och planera kring migreringsaktiviteterna.
I följande tabell visas en typisk migreringsplan:
Migreringsiteration | Startdatum | Beräknat slutdatum | Beroenden | Beräknad varaktighet (i dagar) | Ytterligare information/åtgärdsobjekt |
---|---|---|---|---|---|
PRDCLONE-AUTHOR-INITIAL-USRMAP-SSTAGE-AUTHOR | |||||
PRDCLONE-PUBLISH-TOPUP-CSSTAGE-AUTHOR |
Som du kan se i tabellen ovan är det praktiskt att följa ett specifikt namnformat för att identifiera migreringsiterationerna, till exempel: PRDCLONE för AEM källmiljö, FÖRFATTARE/PUBLICERARE för AEM as a Cloud Service miljö, CSSTAGE-AUTHOR för den AEM as a Cloud Service instansen och så vidare.
Några viktiga detaljer som påverkar migreringsplanen:
Totalt antal extraheringar som krävs
Totalt antal förslag som krävs
Du kan använda flyttningsspåraren för att anteckna tider för både inledande och övre körningar. Dessa datapunkter hjälper dig att formulera realistiska krav på frysning av innehåll innan den sista uppsättningen.
Spåraren hjälper dig även att:
I följande tabell visas en funktionell flyttningsspårare:
Källa (miljö/instans/URL) | Mål (miljö/instans/URL) | Namn på migreringsuppsättning, typ (inledande eller övre) | Storlek på migreringsuppsättning (MB) | Användarmappning (Ja/Nej) | Varaktighet för extrahering (start, slut, tid) | Inmatningstid (start, slut, tid) | Problem / lösningar / Detaljer |
---|---|---|---|---|---|---|---|
I följande avsnitt visas viktiga steg och tillhörande uppgifter som kan användas för att utforma en strategi för innehållsmigrering och tidslinje.
När du har förstått hur du ska bedöma om AEM är redo att flyttas till molnet, och vi har lärt oss hur vi använder de verktyg som behövs för att göra det klart, är det dags att gå vidare till direktfas.