Implementeringsfas implementation-phase

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.

Story hittills story-so-far

I de föregående delarna av resan har du gått igenom bekantat dig med ändringarna i AEM as a Cloud Service och fastställt om din distribution är klar att flyttas till molnet med beredskapsfasen.

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.

Syfte objective

Syftet med detta dokument är att

  • Vi presenterar Cloud Manager, AEM kontinuerliga integrerings- och leveransramverk som används för att distribuera kod till AEM as a Cloud Service
  • Kom igång snabbt med verktyget för innehållsöverföring
  • Beskriv de kodomfaktoriseringsverktyg du måste använda så att du kan uppdatera koden för AEM as a Cloud Service

Använda Cloud Manager using-cloud-manager

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:

Använd verktygen från Adobe för att göra ditt innehåll och din kod i molnet redo use-tools-to-make-code-and-content-cloud-ready

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 viktigaste stegen som ingår i fasen som innebär att konvertera kod och innehåll för användning med AEM as a Cloud Service:

Konverteringssteg

Vi börjar med att gå igenom de verktyg du måste använda så att du kan göra det i kapitlen nedan.

Innehållsmigrering content-migration

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 dokumentationen för verktyget Innehållsöverföring.

Kodomfaktorisering code-refactor

Konfigurera för utveckling set-up-for-development

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 ser du hur du installerar Dispatcher SDK lokalt:

  • I den här videon ser du hur du konfigurerar Dispatcher SDK:

En förändring i sinneset a-change-in-mindset

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 att content och code delas upp i distinkta 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 (d.v.s. 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 oföränderliga områden, vilket innebär att de kan ändras under körning.

Mer information finns i dokumentationen för Rekommenderad paketstruktur.

Migreringsverktyg för molnet cloud-migration-tools

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.

  • Resursarbetsflödesmigrering, ett verktyg som används för att automatiskt migrera arbetsflöden för resursbearbetning
  • Dispatcher Converter, ett verktyg som konverterar dina befintliga Dispatcher-konfigurationer till ett format som är klart för AEM as a Cloud Service.
  • Databasmodernisering, ett verktyg som tar ett AEM flerlägesprojekt som indata och konverterar det till ett AEM as a Cloud Service-projekt
  • Indexkonverteraren, ett verktyg som konverterar index till ett formulär som är kompatibelt med AEM as a Cloud Service
  • Moderniseringsverktyg, en uppsättning verktyg som kan användas för att konvertera äldre AEM till de moderna och stödda funktionerna i AEM as a Cloud Service.

När du har konfigurerat den lokala utvecklingsmiljön kan du bekanta dig med AEM as a Cloud Service SDK genom att läsa dokumentationen.

Schemalägg en fryst kod schedule-a-code-freeze

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 Cloud Manager-pipeline under koddriftsättning och -testning.

NOTE
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.

Bästa metoder för koddriftsättning och testning best-practices

Cloud Manager 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:

  • Testning av kodkvalitet, ett dokument som beskriver processen att skriva testskript och förklarar konceptet med rekommenderad täckning på minst 50 %.
  • Förstå regler för anpassad kodkvalitet som syftar till att beskriva de anpassade regler för kodkvalitet som körs av Cloud Manager och som skapats utifrån bästa praxis från AEM.

Förbereder för GoLive preparing-for-go-live

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 aktivitetsstatusen för revisionsrensningen och datalagrets skräpinsamling. 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.

Datakonsekvenskontroll rekommenderas för alla AEM versioner för att säkerställa att innehållsdatabasen är i ett bra läge för att initiera migreringsaktiviteter.

Åtkomst på systemadministratörsnivå krävs för att installera och konfigurera AZCopy

Vi rekommenderar också att du granskar eventuella oanvända Assets, Sidor, AEM, Projekt, Användare och Grupper för att spara tid vid migreringen. Se avsnittet Hälsa för innehållsdatabas.

Hälsa för innehållsdatabas repository-health

När åtkomsten till en produktionsklona har upprättats fortsätter du med 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 eventuella problem efter migreringen av AEM as a Cloud Service.
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 Resurstillstånd.

Samlar in data gathering-data

NOTE
Avsnittet Strategi för innehållsmigrering och tidslinje innehåller mer information om hur du 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 att upprätta KPI:er och andra migreringsrelaterade åtgärder.

Migreringsplan migration-plan

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, AUTHOR/PUBLISH för AEM as a Cloud Service-miljön, CSSTAGE-AUTHOR för AEM as a Cloud Service-instansen och så vidare.

Några viktiga detaljer som påverkar migreringsplanen:

Totalt antal extraheringar som krävs

  • Utdrag från författare och Publish i specifika miljöer betraktas som två parallella extraktioner eftersom de är oberoende av varandra.
  • Antal Top Up-extraheringar baserat på databastillväxt under specifika tidsperioder.

Totalt antal nödvändiga förslag

  • Det är viktigt att hämta det här objektet till planen, eftersom en extraherad uppsättning kan hämtas in i flera Cloud Service.
  • Antal toppfrågor.
  • Att migrera innehåll från Source Author till Cloud Service Author och från Source Publish till Cloud Service Publish är det bästa sättet att undvika att importera allt Author-innehåll till Cloud Servicen Publish.

Migreringsspårare migration-tracker

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:

  • Identifiera eventuella avvikelser från planeraren som kräver justeringar i tidslinjerna i planen eller i farten
  • Tillhandahålla en realistisk status som kan användas i all nödvändig kommunikation
  • Planera för inledande eller framtida toppmigreringar

I följande tabell visas en funktionell flyttningsspårare:

Source (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

Strategi för innehållsmigrering och tidslinje content-strategyand-timeline

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.

Steg för att formulera en migreringsstrategi

Engagemang fitment

  • Rensning av revisioner, skräpinsamling i datalager och konsekvenskontroller av data. Se även Förbereder för Go-Live

  • Samla statistik om AEM källdatabas:

    • Storlek på segmentbutik
    • Storlek på indexarkiv
    • Antal sidor
    • Antal tillgångar
    • Antal användare och grupper
  • Ta reda på om följande funktioner är aktiverade i AEM (krävs även i AEM as a Cloud Service):

    • Smart taggning
    • Likhetssökning
    • Sök efter text i Word- och PDF-dokument
  • Samla in rapporten från Best Practice Analyzer

  • Importera till Cloud Acceleration Manager

    • Granska självanalysrekommendationen för att säkerställa att AEM as a Cloud Service kan hantera lagringskraven.
  • Skapa en Adobe Support-biljett för eventuella förtydliganden innan du fortsätter med migreringsplanen.

Invandrarnas bevis proof-of-migration

  • Begär en produktionsklona som:

    • Finns i samma nätverkszon
    • Tillhandahåller produktionsinnehåll som användare och grupper
    • Klonar författare och publicering - en nod var om det är ett kluster eller en publiceringsgrupp
  • Välj en delmängd av innehållet som migreras så att:

    • Det är en blandning av alla tillgängliga innehållstyper
    • Innehåller alla användare och grupper
  • Inkluderar antingen 25 % av innehållet eller upp till 1 TB av innehållet, beroende på vilket som är lägst.

  • Utför minst en fullständig migrering och toppöverföring från produktionsklonen till AEM as a Cloud Service icke-produktionsmiljö

  • Lös eventuella problem som:

  • Registrera den tid det tar för extrahering och förtäring:

    • Se hur mycket innehåll som läggs till per vecka
    • Extrapolera de tidpunkter som mäts med hjälp av migreringsbeviset för att skapa en migreringsplan.

What's Next what-is-next

När du har förstått hur du ska bedöma om din AEM är redo att flyttas till molnet, och vi har lärt oss hur du använder de verktyg som behövs för att göra den klar, är det dags att gå vidare till go-live-fasen.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab