Nella fase di implementazione del percorso, esplorerai gli strumenti attraverso i quali puoi rendere il codice e il contenuto pronti per essere trasferiti all’AEM as a Cloud Service.
Nelle parti precedenti del percorso, hai superato familiarità con i cambiamenti dell’AEM as a Cloud Service, nonché per determinare se la distribuzione è pronta per essere spostata nel cloud con fase di preparazione.
Questo articolo continua con consigli su come utilizzare gli strumenti forniti da Adobe per assicurarsi che il codice e il contenuto siano pronti per essere spostati nel cloud.
Il presente documento si prefigge di:
Prima di iniziare, è necessario acquisire familiarità con Cloud Manager, in quanto è l’unico meccanismo per distribuire il codice in AEM as a Cloud Service.
Cloud Manager consente alle organizzazioni di gestire autonomamente AEM nel cloud. Include un framework di integrazione continua e distribuzione continua (CI/CD, Continuous Integration/Continuous Delivery) che consente ai team IT e ai partner dell’implementazione di accelerare la distribuzione di personalizzazioni o aggiornamenti senza compromettere prestazioni o sicurezza.
Per acquisire familiarità con l’utilizzo di Cloud Manager, consulta le risorse seguenti:
Percorso di onboarding per comprendere le risorse di supporto autonomo sull’onboarding, ad Experience Manager as a Cloud Service.
Integrazione di Git con Adobe Cloud Manager per informazioni sull’utilizzo di un archivio Git singolo per implementare il codice.
Configurazione di Adobe Experience as a Cloud Service per informazioni sulla gestione dei prodotti e dell’accesso degli utenti in Admin Console.
I passaggi esatti della transizione al Cloud Service dipendono dai sistemi acquistati e dalle procedure di sviluppo software seguite.
La figura seguente mostra i passaggi principali della fase che comporta la conversione del codice e del contenuto per l’utilizzo con AEM as a Cloud Service:
Nei capitoli seguenti verranno descritti in dettaglio gli strumenti da utilizzare per ottenere questo risultato.
Per migrare il contenuto dall’istanza AEM corrente all’istanza di Cloud Service, puoi utilizzare lo strumento Content Transfer (Trasferimento contenuti) di Adobe.
Con questo strumento, puoi specificare il sottoinsieme di contenuti che desideri trasferire dall’istanza AEM sorgente all’istanza AEM Cloud Service.
La migrazione dei contenuti è un processo in più fasi che richiede pianificazione, tracciamento e collaborazione tra team diversi.
Per informazioni dettagliate su come funziona lo strumento e su come consigliamo di utilizzarlo, vedi Documentazione dello strumento Content Transfer (Trasferimento contenuti).
È ora di iniziare a rieseguire il factoring delle funzioni esistenti per renderle compatibili con i Cloud Services.
A questo scopo, consulta la documentazione che descrive gli strumenti di base necessari per avviare il refactoring del codice:
Inoltre, puoi anche:
Guarda questo video per comprendere come installare localmente l’SDK di Dispatcher:
Guarda questo video per comprendere come configurare l’SDK di Dispatcher:
Lo sviluppo e l’esecuzione del codice in AEM as a Cloud Service richiedono un cambiamento di mentalità. Il codice deve essere resiliente, soprattutto poiché un’istanza potrebbe essere arrestata in qualsiasi momento. Il codice in esecuzione in Cloud Service deve tener conto di essere sempre in esecuzione in un cluster. Ciò significa che ci sono sempre in esecuzione più di un’istanza.
Per rendere i progetti AEM Maven compatibili con il cloud sono necessarie alcune modifiche. AEM as a Cloud Service richiede una separazione di contenuto e codice in pacchetti distinti da distribuire nell’AEM:
/apps
e /libs
sono considerate aree immutabili dell’AEM in quanto non possono essere modificate dopo l’inizio dell’AEM (vale a dire in fase di runtime). Ciò include le operazioni di creazione, aggiornamento o eliminazione. Eventuali tentativi di modifica di un’area immutabile in fase di runtime avranno esito negativo.
Tutto il resto nell’archivio (ad esempio, /content
, /conf
, /var
, /home
, /etc
, /oak:index
, /system
, /tmp
) sono tutte aree mutabili, ovvero possono essere modificate in fase di runtime.
Per saperne di più, consulta Struttura consigliata dei pacchetti documentazione.
Adobe fornisce diversi strumenti per accelerare alcune delle attività di refactoring del codice. Comprendere questi strumenti e i problemi che risolvono ridurrà la complessità e i tempi della migrazione.
Dopo aver configurato l’ambiente di sviluppo locale, acquisisci familiarità con l’SDK as a Cloud Service dell’AEM consultando il documentazione.
Per gestire lo sviluppo del codice in corso sull’AEM attivo insieme alle attività di refactoring del codice come parte del percorso di transizione, ti consigliamo di pianificare un periodo di blocco del codice fino a quando non avrai completato la ristrutturazione del progetto Maven per renderlo compatibile con AEM as a Cloud Service.
Al termine della ristrutturazione del progetto, puoi riprendere lo sviluppo del nuovo codice in base a questa nuova struttura. Questo riduce gli errori della pipeline di Cloud Manager durante la distribuzione e il test del codice.
Le attività di trasferimento dei contenuti e refactoring del codice non devono necessariamente essere eseguite in sequenza. Queste attività possono essere svolte l’una indipendentemente dall’altra. Tuttavia, è necessaria la giusta struttura di progetto per garantire il corretto rendering del contenuto nell’ambiente Cloud Service.
La pipeline di Cloud Manager supporta l’esecuzione di test nell’ambiente di staging.
Segui le best practice riportate nei documenti seguenti relativi al test della qualità del codice:
La preparazione del sistema di origine per la migrazione prevede attività a livello di sistema e di amministratore AEM. Puoi iniziare verificando che l’archivio dei contenuti sia in uno stato di manutenzione corretto controllando pulizia revisioni e raccolta di oggetti inattivi dell’archivio dati stato attività. Se esegui la versione 6.3 dell’AEM (poiché lo strumento Content Transfer (Trasferimento contenuti) è compatibile dalla versione 6.3 in poi), si consiglia di eseguire la compattazione offline, seguita dalla raccolta di oggetti inattivi dell’archivio dati.
Verifica coerenza dati è consigliato in tutte le versioni AEM per garantire che l’archivio dei contenuti in buono stato avvii le attività di migrazione.
Per installare e configurare è necessario disporre dell'accesso a livello di amministratore di sistema AZCopy
È inoltre consigliabile rivedere eventuali risorse, pagine, progetti AEM, utenti e gruppi inutilizzati per risparmiare tempo durante la migrazione. Consulta la Integrità archivio contenuti sezione.
Dopo l’accesso a clone di produzione viene stabilito procedere alla verifica dello stato dell’archivio. Come indicato nella sezione precedente, l’obiettivo è pulire e compattare l’archivio sull’origine prima di avviare la migrazione. Questo passaggio potrebbe risparmiare molto tempo altrimenti, una volta avviata la migrazione, si occuperà della risoluzione dei problemi.
Oggetto Azione | Takeaway chiave |
---|---|
Utenti, gruppi e autorizzazioni | È necessario comprendere il volume di utenti, gruppi e la complessità delle appartenenze. Cerca le opportunità per eliminare eventuali utenti inutilizzati, gruppi nell’origine prima della migrazione. |
Elaborazione risorsa incompleta | Prova a completare l’elaborazione delle risorse nel sistema di origine prima di iniziare la migrazione per evitare potenziali problemi nell’AEM as a Cloud Service dopo la migrazione. |
Integrità dei contenuti | Si consiglia di eseguire una query per individuare eventuali contenuti errati ed eliminarli prima di avviare la migrazione. Ad esempio, cerca le risorse o le pagine che non hanno rappresentazioni originali o che sono bloccate nell’elaborazione del flusso di lavoro. Vedi anche Integrità risorsa. |
Il Strategia e tempistica di migrazione dei contenuti Questa sezione descrive come estrapolare i dati raccolti e creare un piano di migrazione.
La raccolta dei dati può essere utile per pianificare le attività di migrazione e le attività associate. I tempi di estrazione e di acquisizione sono particolarmente utili perché i punti dati possono essere associati a una dimensione specifica del set di migrazione. Di conseguenza, questi punti di dati possono essere estrapolati per ottenere un piano:
Questi punti dati possono anche aiutarti Stabilire i KPI e altre attività relative alla migrazione.
In base ai punti dati raccolti (vedere sopra), è possibile creare un piano di migrazione che può essere integrato in un piano di progetto macro. Questo passaggio consentirà a tutte le principali parti interessate di visualizzare e pianificare le attività di migrazione.
Nella tabella seguente viene illustrato un tipico piano di migrazione:
Iterazione di migrazione | Data iniziale | Data di fine stimata | Dipendenze | Durata stimata (in giorni) | Dettagli aggiuntivi/Azioni |
---|---|---|---|---|---|
PRDCLONE-AUTHOR-INITIAL-USRMAP-CSSTAGE-AUTHOR | |||||
PRDCLONE-PUBLISH-TOPUP-CSSTAGE-AUTHOR |
Come puoi vedere nella tabella precedente, è utile seguire un formato di denominazione specifico per identificare le iterazioni di migrazione, ad esempio: PRDCLONE per l'ambiente AEM di origine , AUTORE/PUBBLICAZIONE per l'ambiente as a Cloud Service dell'AEM, CSSTAGE-AUTHOR per l'istanza AEM as a Cloud Service e così via.
Alcuni dettagli importanti che influenzano il piano di migrazione:
Numero totale di estrazioni richieste
Numero totale di acquisizioni richieste
Puoi utilizzare il tracciatore della migrazione per annotare i tempi sia per le esecuzioni iniziali che per quelle integrative. Questi punti dati ti aiuteranno a formulare requisiti realistici di blocco dei contenuti prima dell’integrazione finale.
Il tracker ti aiuterà anche a:
La tabella seguente illustra un tracker di migrazione funzionale:
Origine (ambiente/istanza/URL) | Destinazione (ambiente/istanza/URL) | Nome e tipo del set di migrazione (iniziale o superiore) | Dimensioni set di migrazione (MB) | Mappatura utenti (sì/no) | Durata estrazione (inizio, fine, tempo impiegato) | Durata acquisizione (inizio, fine, tempo impiegato) | Problemi / Risoluzioni / Dettagli |
---|---|---|---|---|---|---|---|
Nella sezione seguente sono illustrati i passaggi importanti e le attività associate che è possibile utilizzare per formulare una strategia e una tempistica di migrazione dei contenuti.
Una volta compreso appieno come valutare se l’installazione dell’AEM è pronta per essere spostata sul cloud, mentre impariamo a utilizzare gli strumenti necessari per prepararla, è ora di passare al fase di pubblicazione.