Le basi dello sviluppo del codice sono simili in AEM come Cloud Service rispetto alle soluzioni AEM Premise e Managed Services. Gli sviluppatori scrivono il codice e lo sottopongono a test localmente, che vengono quindi spinti AEM remoti come ambienti di Cloud Service. Cloud Manager, uno strumento opzionale per la distribuzione dei contenuti per Managed Services, è richiesto. Questo è ora l'unico meccanismo per distribuire il codice da AEM come ambienti di Cloud Service.
L'aggiornamento della AEM versione è sempre un evento di distribuzione separato dal codice personalizzato. Visualizzate in un altro modo, le versioni di codice personalizzate dovrebbero essere testate rispetto alla versione AEM in produzione, in quanto questo è ciò che verrà distribuito nella parte superiore. AEM aggiornamenti delle versioni che si verificano dopo tale data, che saranno frequenti e vengono applicati automaticamente. Sono compatibili con il codice cliente già distribuito.
Il resto di questo documento descriverà come gli sviluppatori dovrebbero adattare le proprie pratiche in modo che lavorino con AEM come aggiornamenti versione di Cloud Service e aggiornamenti dei clienti.
Si consiglia ai clienti con basi di codice esistenti di seguire l'esercizio di ristrutturazione del repository descritto nella AEM documentazione.
Per le soluzioni AEM precedenti, la versione di AEM più recente è cambiata raramente (approssimativamente ogni anno con Service Pack trimestrali) e i clienti aggiornavano le istanze di produzione all'ultimo avvio rapido in base al proprio tempo, facendo riferimento alla API Jar. Tuttavia, AEM come applicazione di Cloud Service vengono automaticamente aggiornate alla versione più recente di AEM più spesso, pertanto il codice personalizzato per le versioni interne dovrebbe essere creato rispetto alla versione AEM più recente.
Come per le versioni di AEM non cloud esistenti, nella maggior parte dei casi sarà supportato uno sviluppo locale offline basato su uno specifico quickstart, che sarà lo strumento di scelta per il debug.
Esistono sottili differenze operative tra il comportamento dell'applicazione su un computer locale e il Adobe Cloud. Queste differenze architettoniche devono essere rispettate durante lo sviluppo locale e possono portare a un comportamento diverso durante la distribuzione nell'infrastruttura cloud. A causa di queste differenze, è importante eseguire test esaustivi sugli ambienti di sviluppo e di stage prima di distribuire il nuovo codice personalizzato in produzione.
Per sviluppare il codice personalizzato per una versione interna, è necessario scaricare e installare la versione corrispondente del AEM come Cloud Service SDK. Per ulteriori informazioni sull'utilizzo del AEM come strumenti del dispatcher di Cloud Service, vedere questa pagina.
Il seguente video fornisce una panoramica di alto livello su come distribuire il codice da AEM come Cloud Service:
Si consiglia ai clienti con basi di codice esistenti di seguire l'esercizio di ristrutturazione del repository descritto nella AEM documentazione.
I clienti distribuiscono il codice personalizzato agli ambienti cloud tramite Cloud Manager. È opportuno notare che Cloud Manager trasforma i pacchetti di contenuto assemblati localmente in un artefatto conforme al modello di funzioni Sling, che rappresenta la modalità con cui viene descritta un'applicazione AEM come Cloud Service quando viene eseguita in un ambiente cloud. Di conseguenza, quando si esaminano i pacchetti in Package Manager negli ambienti Cloud, il nome includerà "cp2fm" e i pacchetti trasformati hanno tutti i metadati rimossi. Non è possibile interagire con questi elementi, ovvero non possono essere scaricati, replicati o aperti. La documentazione dettagliata sul convertitore si trova qui a1/>.
I pacchetti di contenuto scritti per AEM come applicazioni di Cloud Service devono avere una separazione netta tra contenuto immutabile e mutabile e Cloud Manager lo applicherà non riuscendo a creare, generando un messaggio come:
Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type
Il resto di questa sezione descriverà la composizione e le implicazioni dei pacchetti immutabili e mutabili.
Tutto il contenuto e il codice memorizzati nell’archivio immutabile devono essere sottoposti a check-in e distribuiti tramite Cloud Manager. In altre parole, a differenza delle soluzioni AEM correnti, il codice non viene mai distribuito direttamente in un'istanza AEM in esecuzione. Questo garantisce che il codice in esecuzione per una determinata release in qualsiasi ambiente Cloud sia identico, eliminando il rischio di variazioni di codice non intenzionali durante la produzione. Ad esempio, la configurazione OSGI deve essere impegnata nel controllo del codice sorgente anziché gestita in fase di esecuzione tramite il gestore di configurazione della console Web AEM.
Poiché le modifiche dell'applicazione a causa del pattern di distribuzione Blu-Verde sono abilitate da uno switch, non possono dipendere dalle modifiche nell'archivio modificabile, ad eccezione degli utenti del servizio, dei relativi ACL, dei tipi di nodi e delle modifiche alla definizione dell'indice.
Per i clienti con basi di codice esistenti, è fondamentale seguire l'esercizio di ristrutturazione del repository descritto AEM documentazione per garantire che il contenuto precedentemente in /etc sia spostato nella posizione giusta.
Come già detto, la configurazione OSGI deve essere impegnata nel controllo del codice sorgente anziché tramite la console Web. Le tecniche per farlo includono:
Per ulteriori informazioni sulla configurazione OSGI, vedere Configurazione di OSGi per AEM come Cloud Service.
In alcuni casi potrebbe essere utile preparare le modifiche al contenuto nel controllo del codice sorgente in modo che possa essere distribuito da Cloud Manager ogni volta che un ambiente è stato aggiornato. Ad esempio, potrebbe essere ragionevole generare determinate strutture di cartelle principali o allineare le modifiche nei modelli modificabili per abilitare i criteri in quelli per i componenti che sono stati aggiornati dalla distribuzione dell'applicazione.
Esistono due strategie per descrivere il contenuto che verrà distribuito da Cloud Manager nell'archivio modificabile, i pacchetti di contenuto modificabile e le istruzioni di reindirizzamento.
Contenuto come le gerarchie di percorsi di cartella, gli utenti del servizio e i controlli di accesso (ACL, Access Control) vengono generalmente impegnati in un progetto AEM basato su archetipo principale. Le tecniche includono l'esportazione da AEM o la scrittura direttamente come XML. Durante il processo di creazione e distribuzione, Cloud Manager crea pacchetti per il pacchetto di contenuto variabile risultante. Il contenuto modificabile viene installato in 3 momenti diversi durante la fase di distribuzione nella pipeline:
Prima dell'avvio della nuova versione dell'applicazione:
Durante l'avvio di una nuova versione dell'applicazione, ma prima del passaggio:
Dopo il passaggio alla nuova versione dell'applicazione:
/conf
) (aggiungere, modificare, rimuovere)È possibile limitare l'installazione di contenuti modificabili per creare o pubblicare i pacchetti incorporando i pacchetti in una cartella install.author o install.publish in /apps
. Informazioni da trovare nella AEM documentazione sulla ristrutturazione del progetto consigliata.
I pacchetti di contenuto vengono distribuiti a tutti i tipi di ambiente (dev, stage, prod). Non è possibile limitare la distribuzione a un ambiente specifico. Tale limitazione è in vigore per garantire la possibilità di eseguire un test dell'esecuzione automatica. Il contenuto specifico per un ambiente richiede l'installazione manuale tramite Package Manager.
Inoltre, non esiste alcun meccanismo per ripristinare le modifiche apportate al pacchetto di contenuto modificabile dopo che sono state applicate. Se i clienti rilevano un problema, possono scegliere di risolverlo nella release successiva del codice o come ultima risorsa, ripristinare l'intero sistema a un punto nel tempo prima della distribuzione.
I pacchetti di terze parti inclusi devono essere convalidati come AEM come compatibili con il servizio di Cloud Service, altrimenti la loro inclusione causerà un errore di distribuzione.
Come già detto, i clienti con basi di codice esistenti devono conformarsi all'esercizio di ristrutturazione del repository descritto in AEM documentazione.
Per i seguenti casi, è preferibile adottare l'approccio di codificare manualmente le istruzioni repoinit
per la creazione di contenuti nelle configurazioni di fabbrica OSGI:
Creare/eliminare/disabilitare gli utenti del servizio
Creare ed eliminare gruppi
Creare ed eliminare utenti
Aggiunta di ACL
La definizione di ACL richiede che le strutture dei nodi siano già presenti. Pertanto, prima di creare le istruzioni percorso potrebbe essere necessario.
Aggiungi percorso (ad esempio per le strutture di cartelle principali)
Aggiungere CND (definizioni dei tipi di nodo)
Repoinit è preferibile per questi casi di utilizzo supportati per la modifica del contenuto a causa dei seguenti vantaggi:
Quando Cloud Manager distribuisce l'applicazione, esegue queste istruzioni, indipendentemente dall'installazione di qualsiasi pacchetto di contenuto.
Per creare delle istruzioni di reindirizzamento, attenersi alla procedura seguente:
org.apache.sling.jcr.repoinit.RepositoryInitializer
di fabbrica in una cartella di configurazione del progetto. Utilizzate un nome descrittivo per la configurazione come org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure./content
prima di /content/myfolder
, prima di /content/myfolder/mysubfolder
. Per gli ACL impostati su strutture di basso livello, si consiglia di impostarli su un livello superiore e lavorare con una limitazione rep:glob
. Esempio (allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs))
.Per gli ACL definiti per i nodi al di sotto di /apps
o /libs
l'esecuzione del ripristino verrà avviata in un repository vuoto. I pacchetti vengono installati dopo il riavvio, pertanto le istruzioni non possono basarsi su elementi definiti nei pacchetti, ma devono definire le condizioni preliminari come le strutture padre sottostanti.
Per gli ACL la creazione di strutture profonde potrebbe essere ingombrante, quindi è più ragionevole definire un ACL su un livello più alto e limitare dove si suppone che agisca tramite una restrizione rep:idspn.
Maggiori informazioni sul repoinit sono disponibili nella Documentazione Sling
In alcuni casi, un pacchetto di contenuti deve essere installato come "una tantum". Ad esempio, l'importazione di contenuto specifico dalla produzione all'area di produzione per eseguire il debug di un problema di produzione. Per questi scenari, Package Manager può essere utilizzato in AEM come ambiente di Cloud Service.
Poiché Package Manager è un concetto di runtime, non è possibile installare contenuto o codice nell'archivio immutabile, pertanto questi pacchetti di contenuto devono essere costituiti solo da contenuto variabile (principalmente /content
o /conf
). Se il pacchetto di contenuti include contenuto misto (contenuto modificabile e non modificabile), verrà installato solo il contenuto modificabile.
Tutti i pacchetti di contenuto installati tramite Cloud Manager (sia modificabili che immutabili) verranno visualizzati in uno stato bloccato nell'interfaccia utente di AEM Package Manager. Questi pacchetti non possono essere reinstallati, rigenerati o persino scaricati e saranno elencati con un suffisso "cp2fm", a indicare che l'installazione è stata gestita da Cloud Manager.
È comune per i clienti includere pacchetti pre-costruiti da fonti di terze parti come fornitori di software come Adobi partner di traduzione. Si consiglia di ospitare questi pacchetti in un repository remoto e di farvi riferimento in pom.xml
. Questo è possibile per i repository pubblici e anche per i repository privati con protezione tramite password, come descritto in repository protetti tramite password .
Se non è possibile memorizzare il pacchetto in un archivio remoto, i clienti possono inserirlo in un archivio Maven locale basato su file system, che viene impegnato a SCM come parte del progetto e a cui fanno riferimento qualsiasi cosa dipenda da esso. Il repository è dichiarato nei programmi di progetto illustrati di seguito:
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>
Tutti i pacchetti di terze parti inclusi devono essere conformi al AEM come linee guida di codifica del servizio di Cloud Service e di imballaggio descritte in questo articolo, altrimenti la sua inclusione comporterà un errore di distribuzione.
Il seguente snippet XML Maven POM mostra come incorporare i pacchetti di terze parti nel pacchetto “Container” del progetto, in genere denominato “all”, tramite la configurazione del plug-in Maven filevault-package-maven-plugin.
...
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<subPackages>
<!-- Include the application's ui.apps and ui.content packages -->
...
<!-- Include any other extra packages such as AEM WCM Core Components -->
<!-- Set the version for all dependencies, including 3rd party packages, in the project's Reactor POM -->
<subPackage>
<groupId>com.adobe.cq</groupId>
<artifactId>core.wcm.components.all</artifactId>
<filter>true</filter>
</subPackage>
<subPackage>
<groupId>com.3rdparty.groupId</groupId>
<artifactId>core.3rdparty.artifactId</artifactId>
<filter>true</filter>
</subPackage>
<subPackages>
</configuration>
</plugin>
...
Come AEM aggiornamenti, i rilasci dei clienti vengono distribuiti utilizzando una strategia di implementazione continua per eliminare i tempi di inattività del cluster di autori nelle circostanze giuste. La sequenza generale degli eventi è come descritto di seguito, dove Blue è la vecchia versione del codice cliente e Green è la nuova versione. Blu e Verde eseguono la stessa versione del codice AEM.
Gli indici nuovi o modificati causeranno un ulteriore passaggio di indicizzazione o reindicizzazione prima che la nuova versione (verde) possa iniziare il traffico. Informazioni dettagliate sulla gestione dell'indice in AEM come Cloud Service sono disponibili in questo articolo. Puoi controllare lo stato del processo di indicizzazione nella pagina di compilazione di Cloud Manager e riceverai una notifica quando la nuova versione sarà pronta per il traffico.
Il tempo necessario per una distribuzione continua varia a seconda delle dimensioni dell'indice, poiché la versione verde non può accettare il traffico fino alla generazione del nuovo indice.
Al momento, AEM come Cloud Service non funziona con strumenti di gestione degli indici come lo strumento ACS Commons Assicurare l'indice Oak.
Il meccanismo di pubblicazione è compatibile con le AEM API Java di replica.
Per sviluppare e testare la replica con il servizio di avvio rapido AEM cloud, le funzionalità di replica classica devono essere utilizzate con un’impostazione Autore/Pubblicazione. Nel caso in cui il punto di ingresso dell'interfaccia utente su AEM Author sia stato rimosso per il cloud, gli utenti passavano a http://localhost:4502/etc/replication
per la configurazione.
Come indicato in precedenza, AEM come strategia di implementazione flusso implica che sia le versioni precedenti che quelle nuove possono funzionare contemporaneamente. Di conseguenza, prestate attenzione alle modifiche del codice che non sono compatibili con la versione precedente AEM che è ancora operativa.
Inoltre, la vecchia release deve essere testata per verificare la compatibilità con eventuali nuove strutture di contenuto modificabili applicate dalla nuova release in caso di rollback, dal momento che il contenuto modificabile non viene rimosso.
La modifica degli utenti di servizi o degli ACL necessari per accedere al contenuto o al codice potrebbe causare errori nelle versioni AEM precedenti, con conseguente accesso a tale contenuto o codice con utenti di servizi non aggiornati. Per risolvere questo problema, una raccomandazione consiste nell'apportare modifiche distribuite su almeno 2 rilasci, con la prima release che funge da ponte prima di essere ripulita nella release successiva.
Se vengono apportate modifiche agli indici, è importante che la versione Blu continui a utilizzare i relativi indici fino a quando non viene terminata, mentre la versione Verde utilizza il proprio set modificato di indici. Lo sviluppatore deve seguire le tecniche di gestione dell'indice descritte in questo articolo.
Se un errore viene segnalato o rilevato dopo la distribuzione, è possibile che sia necessario eseguire il rollback alla versione Blu. Sarebbe opportuno garantire che il codice blu sia compatibile con tutte le nuove strutture create dalla versione verde, in quanto le nuove strutture (eventuali contenuti modificabili) non verranno ripristinate. Se il codice precedente non è compatibile, è necessario applicare delle correzioni nelle versioni successive del cliente.
Nelle soluzioni AEM esistenti, i clienti possono eseguire le istanze con modalità di esecuzione arbitrarie e applicare la configurazione OSGI o installare i bundle OSGI a tali istanze specifiche. Le modalità di esecuzione definite in genere includono il servizio (autore e pubblicazione) e l'ambiente (dev, stage, prod).
AEM come Cloud Service, invece, è più opinabile su quali modalità di esecuzione sono disponibili e su come possono essere mappati i bundle OSGI e la configurazione OSGI:
<service>.<environment_type>
, che devono essere utilizzate in questo ordine particolare (ad esempio author.dev
o publish.prod
). I token OSGI devono essere citati direttamente dal codice anziché mediante il metodo getRunModes
, che non includerà più il environment_type
in fase di esecuzione. Per ulteriori informazioni, vedere Configurazione di OSGi per AEM come Cloud Service.install/author
o install/publish
.Come per le soluzioni AEM esistenti, non è possibile utilizzare le modalità di esecuzione per installare solo contenuti per ambienti o servizi specifici. Se si desidera generare un ambiente di sviluppo con dati o HTML non presenti sul palco o sulla produzione, è possibile utilizzare il gestore pacchetti.
Le configurazioni di modalità di esecuzione supportate sono:
Viene utilizzata la configurazione OSGI con le modalità di esecuzione più corrispondenti.
Quando si sviluppa localmente, è possibile passare un parametro di avvio in modalità di esecuzione per stabilire quale configurazione OSGI in modalità di esecuzione verrà utilizzata.
Le configurazioni delle attività di manutenzione devono essere mantenute nel controllo del codice sorgente, dal momento che la schermata Strumenti > Operazioni non sarà più disponibile negli ambienti Cloud. Questo ha il vantaggio di garantire che i cambiamenti siano intenzionalmente persistenti piuttosto che reattivamente applicati e forse dimenticati. Per ulteriori informazioni, fare riferimento all'articolo Attività di manutenzione.