Aggiornamento di codice e personalizzazioni

Durante la pianificazione e l'aggiornamento, è necessario esaminare e affrontare i seguenti aspetti di un'implementazione.

Panoramica

  1. Rilevatore pattern - Eseguite il rilevatore di pattern come descritto nella pianificazione dell'aggiornamento e descritto in dettaglio in questa pagina per ottenere un report del rilevatore di pattern che contenga ulteriori dettagli sulle aree da risolvere in aggiunta alle API/ai bundle non disponibili nella versione di AEM di Target. Il rapporto Rilevamento pattern deve fornire un'indicazione di eventuali incompatibilità nel codice; se non ne sono presenti altre, la distribuzione è già compatibile con la versione 6.5, è comunque possibile scegliere di eseguire un nuovo sviluppo per utilizzare la funzionalità 6.5, ma non è necessario solo per mantenere la compatibilità. In caso di incompatibilità segnalata, è possibile scegliere a) Eseguire in modalità compatibilità e posticipare lo sviluppo per le nuove funzionalità 6.5 o compatibilità, b) decidere di eseguire lo sviluppo dopo l'aggiornamento e passare al passaggio 2. Per ulteriori informazioni, vedere Compatibilità con le versioni precedenti nella AEM 6.5 .

  2. Sviluppare la base codici per la versione 6.5- Creare un ramo o un repository dedicato per la base codice per la versione di Target. Utilizzate le informazioni provenienti dalla compatibilità pre-aggiornamento per pianificare aree di codice da aggiornare.

  3. Compilare con 6.5 Uber jar- Aggiornare i POM della base di codice in modo che puntino a 6.5 uber jar e compilare il codice in base a questo.

  4. Aggiornamento AEM Personalizzazioni* - *Eventuali personalizzazioni o estensioni da AEM devono essere aggiornate/convalidate per funzionare in 6.5 e aggiunte alla base di codici 6.5. Include Forms per la ricerca nell’interfaccia utente, Personalizzazioni risorse con /mnt/overlay

  5. Distribuisci in ambiente 6.5: in un ambiente Dev/QA deve essere presente un'istanza pulita di AEM 6.5 (Autore + Pubblica). È necessario aggiornare la base di codice e distribuire un campione rappresentativo di contenuto (proveniente dalla produzione corrente).

  6. Convalida della qualità e correzione dei bug - QA deve convalidare l'applicazione sia nelle istanze Author che Publish di 6.5. Eventuali bug rilevati devono essere corretti e impegnati nella base di codici 6.5. Ripetere Dev-Cycle secondo necessità fino a risolvere tutti i bug.

Prima di procedere con l'aggiornamento è necessario disporre di una base di codice applicativo stabile che sia stata accuratamente testata rispetto alla versione di destinazione del AEM. Sulla base delle osservazioni fatte durante il test, potrebbero esserci modi per ottimizzare il codice personalizzato. Ciò potrebbe includere il refactoring del codice per evitare l'attraversamento del repository, l'indicizzazione personalizzata per ottimizzare la ricerca o l'uso di nodi non ordinati in JCR, tra gli altri.

Oltre all'opzione di aggiornare la base di codice e le personalizzazioni per l'utilizzo con la nuova versione AEM, la versione 6.5 consente anche di gestire le personalizzazioni in modo più efficiente con la funzione Compatibilità con le versioni precedenti, come descritto in questa pagina.

Come indicato in precedenza e illustrato nel diagramma di seguito, l'esecuzione di Rilevatore pattern nel primo passaggio consente di valutare la complessità complessiva dell'aggiornamento e se si desidera eseguire in modalità di compatibilità o aggiornare le personalizzazioni per utilizzare tutte le nuove funzioni di AEM 6.5. Per ulteriori informazioni, vedere la pagina Compatibilità con le versioni precedenti di AEM 6.5 .
opt_cropped

Aggiorna la base codici

Crea un ramo dedicato per il codice 6.5 nel controllo delle versioni

Tutti i codici e le configurazioni richiesti per l'implementazione AEM devono essere gestiti utilizzando un qualche tipo di controllo della versione. È necessario creare un ramo dedicato nel controllo della versione per gestire tutte le modifiche necessarie per la base di codice nella versione di destinazione del AEM. In questo ramo verrà gestito il test iterativo della base di codice rispetto alla versione di destinazione di AEM e correzioni di bug successive.

Aggiornamento della versione AEM Uber Jar

AEM Uber jar include tutte AEM API come una singola dipendenza nel progetto Maven pom.xml. È sempre consigliabile includere Uber Jar come singola dipendenza invece di includere singole dipendenze API AEM. Quando si aggiorna la base di codice, la versione di Uber Jar deve essere modificata in modo da puntare alla versione di destinazione di AEM. Se il progetto è stato sviluppato su una versione di AEM prima dell'esistenza di Uber Jar, tutte le singole dipendenze API AEM devono essere rimosse e sostituite da un'unica inclusione dell'Uber Jar per la versione di destinazione di AEM. La base di codice deve quindi essere ricompilata con la nuova versione di Uber Jar. Eventuali API o metodi obsoleti devono essere aggiornati per essere compatibili con la versione di destinazione di AEM.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.5.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Eliminazione graduale dell'utilizzo di Administrative Resource Resolver

L'uso di una sessione amministrativa attraverso SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() era abbastanza diffuso in basi di codice prima di AEM 6.0. Tali metodi sono stati dichiarati obsoleti per motivi di sicurezza, in quanto forniscono un livello di accesso troppo ampio. Nelle versioni future di Sling questi metodi verranno rimossi. Si consiglia vivamente di rigenerare il codice in modo da utilizzare gli utenti del servizio. Maggiori informazioni sugli utenti dei servizi e come eliminare gradualmente le sessioni amministrative sono disponibili qui.

Query e indici Oak

Qualsiasi utilizzo di query nella base di codici deve essere accuratamente testato nell'ambito dell'aggiornamento della base di codice. Per i clienti che effettuano l’aggiornamento da Jackrabbit 2 (versioni AEM precedenti alla 6.0), questo è particolarmente importante, in quanto Oak non indicizza automaticamente il contenuto e potrebbe essere necessario creare indici personalizzati. Se si esegue l'aggiornamento da una versione AEM 6.x, le definizioni dell'indice Oak potrebbero essere cambiate e avere effetti sulle query esistenti.

Sono disponibili diversi strumenti per l’analisi e l’analisi delle prestazioni delle query:

Classic UI Authoring

L’authoring con l’interfaccia classica è ancora disponibile in AEM 6.5 ma non è più disponibile. More information can be found here. Se l’applicazione è attualmente in esecuzione nell’ambiente di authoring dell’interfaccia classica, si consiglia di effettuare l’aggiornamento a AEM 6.5 e continuare a utilizzare l’interfaccia classica. La migrazione all'interfaccia utente touch può essere pianificata come progetto separato da completare in diversi cicli di sviluppo. Per utilizzare l’interfaccia classica in AEM 6.5, sono necessarie diverse configurazioni OSGi per il commit nella base di codice. Per ulteriori dettagli su come configurare questa funzione, consulta qui.

Allinea con struttura archivio 6.5

Per semplificare gli aggiornamenti e garantire che le configurazioni non vengano sovrascritte durante un aggiornamento, il repository viene ristrutturato in 6.4 per separare il contenuto dalla configurazione.

Pertanto, alcune impostazioni devono essere spostate per non risiedere più /etc come in passato. Per esaminare l’intera serie di problemi di ristrutturazione del repository che devono essere esaminati e inseriti nell’aggiornamento al AEM 6.4, cfr. Ristrutturazione del repository AEM 6.4.

Personalizzazioni AEM

È necessario identificare tutte le personalizzazioni all’ambiente di authoring AEM nella versione di AEM di origine. Una volta identificati, si consiglia di memorizzare ciascuna personalizzazione nel controllo della versione o almeno di eseguire il backup come parte di un pacchetto di contenuti. Tutte le personalizzazioni devono essere distribuite e convalidate in un ambiente QA o Staging che esegue la versione di destinazione di AEM prima di un aggiornamento della produzione.

Sovrapposizioni in generale

È pratica comune estendere AEM fuori dalla funzionalità box sovrapponendo nodi e/o file in /libs con nodi aggiuntivi in /apps. Queste sovrapposizioni devono essere tracciate nel controllo della versione e verificate in base alla versione di destinazione del AEM. Se un file (sia JS, JSP, HTL) è sovrapposto, si consiglia di lasciare un commento su quale funzionalità è stata aumentata per un test di regressione più semplice sulla versione di destinazione di AEM. Ulteriori informazioni sulle sovrapposizioni in generale sono disponibili qui. Le istruzioni per specifiche sovrapposizioni AEM sono disponibili di seguito.

Aggiornamento della ricerca personalizzata per Forms

I facet di ricerca personalizzati richiedono alcune regolazioni manuali dopo l'aggiornamento per funzionare correttamente. Per ulteriori dettagli, consultate Aggiornamento della ricerca personalizzata per Forms.

Personalizzazioni interfaccia utente Risorse

Nota

Questa procedura è necessaria solo per gli aggiornamenti da versioni precedenti alla AEM 6.2.

Le istanze che dispongono di distribuzioni di risorse personalizzate devono essere preparate per l’aggiornamento. Ciò è necessario per garantire che tutto il contenuto personalizzato sia compatibile con la nuova struttura di nodi 6.4.

Per preparare le personalizzazioni all’interfaccia utente delle risorse, effettua le seguenti operazioni:

  1. Nell’istanza che deve essere aggiornata, aprite il CRXDE Lite https://server:port/crx/de/index.jsp

  2. Vai al nodo seguente:

    • /apps/dam/content
  3. Rinominare il nodo di contenuto in content_backup. Per eseguire questa operazione, fare clic con il pulsante destro del mouse sul riquadro dell'elenco delle cartelle nella parte sinistra della finestra e scegliere Rinomina.

  4. Dopo aver rinominato il nodo, crea un nuovo nodo denominato content in /apps/dam named content e imposta il tipo di nodo su sling:Folder.

  5. Sposta tutti i nodi figlio di content_backup nel nodo di contenuto appena creato. A tale scopo, fare clic con il pulsante destro del mouse su ciascun nodo figlio nel riquadro di esplorazione e selezionare Sposta.

  6. Eliminate il nodo content_backup .

  7. I nodi aggiornati sotto /apps/dam con il tipo di nodo corretto di sling:Folder dovrebbero idealmente essere salvati nel controllo della versione e distribuiti con la base di codice o almeno sottoposti a backup come pacchetto di contenuto.

Generazione degli ID risorsa per le risorse esistenti

Per generare ID di risorse per le risorse esistenti, aggiornate le risorse quando aggiornate l’istanza AEM in modo da eseguire AEM 6.5. Questa funzione è necessaria per abilitare la funzione Risorse approfondite. Per ulteriori dettagli, consultate Aggiungere il codiceda incorporare.

Per aggiornare le risorse, configura il pacchetto Associate Asset ID (ID risorsa associati) nella console JMX. A seconda del numero di risorse presenti nella directory archivio, migrateAllAssets potrebbe essere necessario molto tempo. I nostri test interni stimano circa un'ora per 125mila asset su TarMK.

1487758945977

Se avete bisogno di ID risorsa per un sottoinsieme di tutte le risorse, utilizzate l' migrateAssetsAtPath API.

Per tutti gli altri scopi, utilizzate l' migrateAllAssets() API.

Personalizzazioni script InDesign

Adobe consiglia di inserire script personalizzati in /apps/settings/dam/indesign/scripts posizione. Ulteriori informazioni sulle personalizzazioni script InDesign sono disponibili qui.

Ripristino delle configurazioni ContextHub

Le configurazioni ContextHub sono interessate da un aggiornamento. Le istruzioni su come recuperare le configurazioni ContextHub esistenti sono disponibili qui.

Personalizzazioni flusso di lavoro

È pratica comune aggiornare i flussi di lavoro di modifica per aggiungere o rimuovere funzionalità non necessarie. Un flusso di lavoro comune personalizzato è il flusso di lavoro Aggiorna risorsa DAM. Tutti i flussi di lavoro necessari per un'implementazione personalizzata devono essere sottoposti a backup e memorizzati nel controllo delle versioni, in quanto possono essere sovrascritti durante un aggiornamento.

Modelli modificabili

Nota

Questa procedura è necessaria solo per gli aggiornamenti di Siti che utilizzano Modelli modificabili di AEM 6.2

La struttura dei modelli modificabili è cambiata tra AEM 6.2 e 6.3. Se state effettuando l’aggiornamento dalla versione 6.2 o precedente e il contenuto del sito è stato creato utilizzando modelli modificabili, dovrete utilizzare lo strumento Pulizia nodireattivi. Lo strumento deve essere eseguito dopo un aggiornamento per ripulire il contenuto. Dovrà essere eseguito su livelli Autore e Pubblica.

Modifiche all’implementazione CUG

L'implementazione di Gruppi di utenti chiusi è cambiata notevolmente per risolvere i limiti di prestazioni e scalabilità nelle versioni precedenti di AEM. La versione precedente di CUG era obsoleta in 6.3 e la nuova implementazione era supportata solo nell’interfaccia touch. Se state effettuando l’aggiornamento dalla versione 6.2 o precedente, le istruzioni per effettuare la migrazione alla nuova implementazione CUG sono disponibili qui.

Procedura di prova

Dovrebbe essere preparato un piano di test completo per gli aggiornamenti di test. La verifica della base di codice aggiornata e dell’applicazione dovrà essere eseguita innanzitutto in ambienti più bassi. Eventuali bug rilevati devono essere corretti in modo iterativo fino a quando la base del codice non è stabile, solo allora gli ambienti di livello superiore dovrebbero essere aggiornati.

Verifica della procedura di aggiornamento

La procedura di aggiornamento come illustrato di seguito deve essere testata sugli ambienti Dev e QA come documentato nel manuale di esecuzione personalizzato (vedere Pianificazione dell'aggiornamento). La procedura di aggiornamento deve essere ripetuta fino a quando tutte le fasi non sono documentate nel libro di esecuzione dell'aggiornamento e il processo di aggiornamento non è uniforme.

Aree di test di implementazione

Di seguito sono riportate le aree critiche di ogni implementazione AEM che dovrebbe essere coperta dal piano di test una volta che l'ambiente è stato aggiornato e che la base di codice aggiornata è stata implementata.

Area di prova funzionale Descrizione
Siti pubblicati Verificare l’implementazione AEM e il codice associato sul livello
di pubblicazione tramite il dispatcher. Deve includere criteri per gli aggiornamenti delle pagine e per
l’annullamento della validità della cache.
Authoring Verificare l’implementazione AEM e il codice associato nel livello Autore. Deve includere finestre di dialogo e di authoring delle pagine e dei componenti.
Integrazioni con le soluzioni di Marketing Cloud Convalida delle integrazioni con prodotti come Analytics, DTM e Target.
Integrazioni con i sistemi di terze parti Le eventuali integrazioni di terze parti devono essere convalidate sia sui livelli Autore che Pubblica.
Autenticazione, sicurezza e autorizzazioni Eventuali meccanismi di autenticazione come LDAP/SAML devono essere convalidati.
Le autorizzazioni e i gruppi devono essere testati sia sui livelli Autore che Pubblica
.
Query Gli indici e le query personalizzati devono essere testati insieme alle prestazioni delle query.
Personalizzazioni interfaccia utente Eventuali estensioni o personalizzazioni dell’interfaccia AEM nell’ambiente di authoring.
Flussi di lavoro Flussi di lavoro e funzionalità personalizzati e/o non inclusi.
Test delle prestazioni Il test del carico deve essere eseguito sia sui livelli Autore che Pubblica per simulare scenari reali.

Piano di test del documento e risultati

Occorre creare un piano di prova che copra le aree di prova di attuazione sopra indicate. In molti casi sarà utile separare il piano di test dagli elenchi delle attività Autore e Pubblica. Questo piano di test deve essere eseguito negli ambienti Dev, QA e Stage prima di aggiornare gli ambienti Produzione. I risultati dei test e le metriche delle prestazioni devono essere acquisiti in ambienti inferiori per fornire un confronto quando si aggiornano gli ambienti Stage e Produzione.

In questa pagina