Aggiornamenti della versione di AEM aem-version-updates
Scopri in che modo Adobe Experience Manager (AEM) as a Cloud Service utilizza l’integrazione e la distribuzione continue (CI/CD) per mantenere i progetti sull’ultima versione.
CI/CD ci-cd
AEM as a Cloud Service utilizza l’integrazione continua e la distribuzione continua (CI/CD) per garantire che i progetti utilizzino la versione AEM più recente. Questo processo aggiorna facilmente le istanze di produzione, staging e sviluppo senza causare interruzioni agli utenti.
Prima che le istanze vengano aggiornate automaticamente, viene pubblicata una nuova versione di manutenzione dell’AEM con 3-5 giorni di anticipo. Durante questo periodo, l'istanza di sviluppo potrebbe essere aggiornata automaticamente o, nel caso sia disponibile, puoi facoltativamente attivare l'aggiornamento per le istanze di sviluppo. Gli aggiornamenti delle versioni vengono prima applicati automaticamente agli ambienti di sviluppo. Se l’aggiornamento ha esito positivo, il processo di aggiornamento procede alle istanze di staging e produzione. Le istanze di sviluppo e staging fungono da gate di qualità automatizzato, in cui i test scritti personalizzati vengono eseguiti prima dell’applicazione dell’aggiornamento all’ambiente di produzione.
NIMU (aggiornamenti di manutenzione non intrusivi) nimu
Gli aggiornamenti di manutenzione non intrusivi sono aggiornamenti automatici applicati senza coinvolgere le pipeline dei clienti.
Tramite NIMU, il cliente può utilizzare la pipeline in qualsiasi momento, anche se è pianificato o in corso un aggiornamento della versione dell’AEM e gli aggiornamenti di manutenzione non verranno più visualizzati nella cronologia di esecuzione della pipeline del cliente, semplificando il monitoraggio della cronologia delle distribuzioni del codice.
Aggiorna attività
La versione corrente dell’AEM può ancora essere controllata per ogni ambiente, come prima, utilizzando il pannello Ambienti dell’interfaccia utente di Cloud Manager. Gli stessi gate di qualità utilizzati nella pipeline vengono utilizzati dagli aggiornamenti di manutenzione non intrusivi, inclusi i test scritti dal cliente.
Una notifica dell'interfaccia utente di Cloud Manager verrà inviata ogni volta che viene applicato un aggiornamento di manutenzione non intrusivo agli ambienti del programma. Puoi configurarlo per l’invio anche all’e-mail.
Tipo di aggiornamenti update-types
Esistono due tipi di aggiornamenti delle versioni di AEM:
-
Aggiornamenti di manutenzione AEM
- Sono per lo più a scopo di manutenzione, comprese le ultime correzioni di bug e gli aggiornamenti di sicurezza.
- L’impatto è minimo perché le modifiche vengono applicate regolarmente.
-
- Vengono rilasciati in base a una pianificazione mensile prevedibile.
Errore di aggiornamento update-failure
Gli aggiornamenti AEM passano attraverso una pipeline di convalida del prodotto intensa e completamente automatizzata che coinvolge più fasi, garantendo l'assenza di interruzioni del servizio per tutti i sistemi in produzione. I controlli di integrità vengono utilizzati per monitorare lo stato dell'applicazione. Se questi controlli non vanno a buon fine durante un aggiornamento di AEM as a Cloud Service, la versione non procede e Adobe indaga il motivo per cui l’aggiornamento ha causato questo comportamento imprevisto.
Quando distribuisci una nuova versione del codice personalizzato nel tuo ambiente, I test funzionali del prodotto e personalizzati svolgono un ruolo cruciale. Essi garantiscono che i sistemi di produzione rimangano stabili e funzionanti anche dopo l’applicazione di una modifica. Questi test vengono applicati anche nel processo di aggiornamento della versione AEM.
Se l’aggiornamento dell’ambiente di produzione non riesce, Cloud Manager ripristina automaticamente l’ambiente di staging. Questa operazione viene eseguita automaticamente per assicurarsi che al termine di un aggiornamento, entrambi gli ambienti di staging e produzione utilizzino la stessa versione dell’AEM.
Analogamente, se un aggiornamento automatico di un ambiente di sviluppo non riesce, gli ambienti di staging e produzione non vengono aggiornati.
Best practice best-practices
-
Utilizzo ambiente di staging
- Utilizza un ambiente diverso (non stage) per lunghi cicli di QA/UAT.
- Una volta completato il test di integrità su Stage, spostati per verificare in Produzione.
-
Pipeline di produzione
- Sospendi prima di implementare in produzione.
- L'annullamento della pipeline dopo una distribuzione di staging indica che il codice è "uno scarto" e non è un candidato valido per la produzione. Fare riferimento a Configurazione di una pipeline di produzione.
-
Pipeline non di produzione
- Configura una pipeline non di produzione.
- Accelerare la velocità/frequenza di consegna in caso di errori della pipeline di produzione. Identifica i problemi nelle pipeline non di produzione abilitando i test funzionali del prodotto, i test funzionali personalizzati e i test dell’interfaccia utente personalizzati.
-
Copia contenuto
- Utilizza Copia contenuto per spostare set di contenuti simili in un ambiente non di produzione.
-
Test funzionali automatizzati
- Includi test automatizzati nella pipeline per testare le funzionalità critiche.
- I test funzionali del cliente e i test dell'interfaccia utente personalizzati sono bloccati se non riescono a eseguire il rollout della versione dell'AEM.
Regressione regression
Se riscontri un problema relativo alla regressione, invia un caso di supporto tramite l’Admin Console. Se il problema è un bloccante e il suo impatto sulla produzione, deve essere sollevato un P1. Fornire tutti i dettagli necessari per riprodurre il problema di regressione.
Archivio nodi compositi composite-node-store
In genere, gli aggiornamenti non comportano tempi di inattività, incluso per l’istanza di authoring, che è un cluster di nodi. Aggiornamenti continui sono possibili a causa di la funzionalità archivio nodi composito in Oak.
Questa funzione consente all’AEM di fare riferimento simultaneamente a più archivi. In una distribuzione continua, la nuova versione dell'AEM contiene il proprio /libs
(l'archivio immutabile basato su TarMK). Si distingue dalla versione precedente dell'AEM, anche se entrambi fanno riferimento a un archivio condivise mutabile basato su DocumentMK che contiene aree come /content
, /conf
, /etc
e altri.
Poiché sia la versione precedente che quella nuova hanno versioni proprie di /libs
, possono essere entrambe attive durante l'aggiornamento continuo. E, entrambi possono prendere il traffico fino a quando il vecchio è completamente sostituito dal nuovo.
Ulteriori informazioni further-information
Per maggiori dettagli sui temi correlati: