Nella fase di implementazione del percorso, esplorerai gli strumenti attraverso i quali puoi rendere il codice e il contenuto pronto per essere spostato in AEM as a Cloud Service.
Nelle parti precedenti del percorso, avete attraversato acquisire familiarità con le modifiche in AEM as a Cloud Service, nonché determinare se la distribuzione è pronta per essere spostata nel cloud con l’ 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 mira a:
Prima di iniziare, devi acquisire familiarità con Cloud Manager, in quanto è l’unico meccanismo per distribuire il codice 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:
Onboarding per Experience Manager as a Cloud Service per comprendere le risorse disponibili sull’onboarding per 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 da utilizzare con AEM as a Cloud Service:
Inizieremo a fornire dettagli sugli strumenti necessari per ottenere questo risultato nei capitoli seguenti.
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 complete sul funzionamento dello strumento e su come consigliamo di utilizzarlo, consulta la sezione Documentazione dello strumento Content Transfer (Trasferimento contenuti).
È il momento di iniziare a ripristinare le funzionalità esistenti in modo che siano compatibili con i Cloud Services.
Per eseguire questa operazione, è necessario consultare la documentazione che descrive in dettaglio gli strumenti di base necessari per iniziare a eseguire il refactoring del codice:
Inoltre, puoi anche:
Guarda questo video per scoprire come installare localmente l’SDK di Dispatcher:
Guarda questo video per scoprire come configurare l’SDK di Dispatcher:
Lo sviluppo e l'esecuzione del codice in AEM as a Cloud Service richiede una modifica nella 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.
Alcune modifiche sono necessarie affinché i progetti Maven AEM siano compatibili con il cloud. AEM as a Cloud Service richiede una separazione content e codice in pacchetti distinti per la distribuzione in AEM:
/apps
e /libs
sono considerate aree immutabili di AEM in quanto non possono essere modificate dopo l’inizio di AEM (cioè 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, il che significa che possono essere modificate in fase di runtime.
Per saperne di più, consulta la Struttura del pacchetto consigliata 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 il tempo della migrazione.
Dopo aver configurato l’ambiente di sviluppo locale, acquisisci familiarità con l’SDK as a Cloud Service AEM consultando il documentazione.
Per gestire lo sviluppo del codice in corso sul tuo 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 l’implementazione 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 eseguiti sull’ambiente stage.
Segui le best practice riportate nei documenti seguenti per quanto riguarda il test della qualità del codice:
La preparazione del sistema di origine per la migrazione comporta l’esecuzione di attività a livello di sistema e AEM amministratore. Puoi iniziare verificando che l’archivio dei contenuti sia in buono stato controllando la pulizia revisioni e raccolta oggetti inattivi dell'archivio dati stato dell'attività. Se esegui AEM versione 6.3 (in quanto lo strumento Content Transfer (Trasferimento contenuti) è compatibile a partire dalla versione 6.3), si consiglia di eseguire la compattazione offline, seguita dalla raccolta degli oggetti inattivi nell’archivio dati.
Controllo della coerenza dei dati è consigliato in tutte le versioni di AEM per garantire che l’archivio dei contenuti sia in buono stato per avviare le attività di migrazione.
L'accesso a livello di amministratore di sistema è necessario per installare e configurare AZCopy
È inoltre consigliabile esaminare tutte le risorse, le pagine, i progetti AEM, gli utenti e i gruppi non utilizzati per risparmiare tempo sulla migrazione. Consulta la sezione Stato dell’archivio dei contenuti sezione .
Una volta effettuato l’accesso a un clone di produzione è stabilito procedere per controllare lo stato di salute dell'archivio. Come indicato nella sezione precedente, l’obiettivo è quello di pulire e compattare l’archivio sulla sorgente prima di avviare la migrazione. Questo passaggio potrebbe potenzialmente risparmiare molto tempo altrimenti si spenderà per la risoluzione dei problemi una volta avviata la migrazione.
Elemento azione | Aree principali |
---|---|
Utenti, gruppi e autorizzazioni | È necessario comprendere il volume di utenti, gruppi e la complessità intorno alle appartenenze. Cerca le opportunità per ripulire gli utenti e i gruppi inutilizzati nella sorgente prima della migrazione. |
Elaborazione delle risorse incompleta | Prova a completare l’elaborazione delle risorse nel sistema di origine prima di avviare la migrazione per evitare potenziali problemi AEM migrazione as a Cloud Service dopo la migrazione. |
Salute dei contenuti | È consigliabile eseguire una query per individuare il contenuto non valido ed eliminarlo prima di avviare la migrazione. Ad esempio, cerca le risorse o le pagine prive di rendering originali o bloccate nell’elaborazione del flusso di lavoro. Vedi anche Salute risorse. |
La Strategia e cronologia di migrazione dei contenuti sezione ulteriori dettagli su 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 acquisizione sono particolarmente utili perché i punti dati possono essere associati a una dimensione specifica del set di migrazione. Come tale, questi punti dati possono essere estrapolati per elaborare un piano:
Un altro punto dati importante è il tempo necessario per completare il mappatura utente, se questa è associata alla migrazione dei contenuti. Puoi prendere in considerazione questo punto dati per stime più realistiche, in quanto verrà aggiunto alla timeline di estrazione complessiva e potrebbe non essere necessario eseguirlo durante le operazioni integrative.
Questi punti dati possono anche essere utili Stabilire i KPI e altre attività relative alla migrazione.
In base ai punti dati raccolti (vedi 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.
La tabella seguente illustra un tipico piano di migrazione:
Iterazione di migrazione | Data iniziale | Data di fine stimata | Dipendenze | Durata stimata (in giorni) | Dettagli aggiuntivi / Elementi azione |
---|---|---|---|---|---|
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 sorgente , AUTORE/PUBBLICA per l'ambiente AEM as a Cloud Service, CSSTAGE-AUTHOR per l'istanza AEM as a Cloud Service e così via.
Alcuni importanti dettagli che influenzano il piano di migrazione:
Numero totale di estrazioni richieste
Numero totale di gestioni richieste
Puoi utilizzare il tracciamento della migrazione per annotare i tempi per le esecuzioni iniziali e superiori. 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 funzionale di migrazione:
Origine (Ambiente/Istanza/URL) | Destinazione (Ambiente/Istanza/URL) | Nome set di migrazione, tipo (iniziale o superiore) | Dimensioni set di migrazione (MB) | Mappatura utente (Sì / No) | Durata estrazione (inizio, fine, ora) | Durata dell’acquisizione (inizio, fine, ora presa) | Problemi / Risoluzioni / Dettagli |
---|---|---|---|---|---|---|---|
La sezione seguente illustra i passaggi importanti e le attività associate che possono essere utilizzati per formulare una strategia e una cronologia di migrazione dei contenuti.
Una volta compreso come valutare se l'installazione AEM è pronta per essere spostata nel cloud, mentre impariamo come utilizzare gli strumenti necessari per renderla pronta, è il momento di passare al fase di go-live.