Per informazioni sulla distribuzione del codice per Cloud Manager in AEM as a Cloud Service, vedi qui.
Dopo aver configurato la pipeline di produzione (archivio, ambiente e ambiente di test), è possibile distribuire il codice.
Fai clic su Distribuzione da Cloud Manager per avviare il processo di distribuzione.
La Esecuzione della pipeline viene visualizzato lo schermo.
Fai clic su Crea per avviare il processo.
Il processo di compilazione completo distribuisce il codice.
Nel processo di creazione sono coinvolte le seguenti fasi:
Inoltre, puoi rivedere i passaggi dei vari processi di distribuzione visualizzando i registri o rivedendo i risultati per i criteri di test.
La distribuzione della fase prevede i seguenti passaggi:
La Test della fase, prevede i seguenti passaggi:
La Distribuzione di produzione, prevede i seguenti passaggi:
La Pianificazione distribuzione produzione viene attivato durante la configurazione della pipeline.
Utilizzando questa opzione, puoi pianificare la distribuzione di produzione oppure fare clic su Ora per eseguire immediatamente la distribuzione di produzione.
La data e l’ora pianificate vengono specificate in termini di fuso orario dell’utente.
Fai clic su Conferma per verificare le impostazioni.
Una volta confermata la pianificazione della distribuzione, la distribuzione del codice viene completata.
Viene visualizzata la seguente schermata, quando Ora è selezionata dal passaggio precedente.
I seguenti passaggi si interrompono se rimangono in attesa del feedback degli utenti:
Incremento | Timeout |
---|---|
Test della qualità del codice | 14 giorni |
Test di sicurezza | 14 giorni |
Test delle prestazioni | 14 giorni |
Domanda di approvazione | 14 giorni |
Pianificazione distribuzione produzione | 14 giorni |
Supporto CSE | 14 giorni |
La sezione seguente descrive come i pacchetti AEM e dispatcher vengono distribuiti nella fase di stage e nella fase di produzione.
Cloud Manager carica tutti i file target/*.zip prodotti dal processo di compilazione in una posizione di archiviazione. Questi artefatti vengono recuperati da questa posizione durante le fasi di distribuzione della pipeline.
Quando Cloud Manager viene implementato in topologie non di produzione, l’obiettivo è quello di completare l’implementazione il più rapidamente possibile e, pertanto, gli artefatti vengono distribuiti simultaneamente su tutti i nodi come segue:
Cloud Manager determina se ogni artefatto è un pacchetto AEM o dispatcher.
Cloud Manager rimuove tutti i dispatcher dal Load Balancer per isolare l’ambiente durante la distribuzione.
A meno che non sia configurato diversamente, è possibile saltare le modifiche del Load Balancer nelle implementazioni di sviluppo e stage, ovvero scollegare e allegare i passaggi sia nelle pipeline non di produzione, per gli ambienti di sviluppo e nella pipeline di produzione, per gli ambienti di stage.
Questa funzione dovrebbe essere utilizzata principalmente da 1-1-1 clienti.
Ciascun artefatto AEM viene distribuito a ogni istanza AEM tramite API di Gestione pacchetti, con dipendenze dei pacchetti che determinano l’ordine di distribuzione.
Per ulteriori informazioni su come utilizzare i pacchetti per installare nuove funzionalità, trasferire contenuti tra le istanze e eseguire il backup del contenuto dell’archivio, consulta Come utilizzare i pacchetti.
Tutti gli artefatti AEM vengono distribuiti sia all’autore che agli editori. Le modalità di esecuzione devono essere utilizzate quando sono necessarie configurazioni specifiche per il nodo. Per ulteriori informazioni su come le modalità di esecuzione consentono di ottimizzare l'istanza AEM per uno scopo specifico, consulta Modalità di esecuzione .
L’artefatto del dispatcher viene distribuito a ciascun dispatcher come segue:
httpd
directory. I file immutabili non vengono sovrascritti. Eventuali modifiche apportate ai file immutabili nell’archivio Git verranno ignorate al momento della distribuzione. Questi file sono di base del framework del dispatcher AMS e non possono essere modificati.Cloud Manager prevede che l’artefatto del dispatcher contenga l’intero set di file. Tutti i file di configurazione del dispatcher devono essere presenti nell’archivio Git. File o cartelle mancanti causeranno un errore di distribuzione.
Dopo la corretta distribuzione di tutti i pacchetti AEM e dispatcher a tutti i nodi, i dispatcher vengono aggiunti nuovamente al load balancer e la distribuzione è completa.
È possibile saltare le modifiche di Load Balancer nelle distribuzioni di sviluppo e stage, ovvero scollegare e allegare i passaggi sia nelle pipeline non di produzione, per gli ambienti di sviluppo e nella pipeline di produzione, per gli ambienti di stage.
Il processo di distribuzione nelle topologie di produzione è leggermente diverso per ridurre al minimo l’impatto sui visitatori AEM sito.
Le distribuzioni di produzione seguono generalmente gli stessi passaggi indicati in precedenza, ma in modo continuo:
In situazioni critiche, i clienti di Adobe Managed Services potrebbero dover implementare modifiche al codice nei rispettivi ambienti di stage e produzione senza attendere l’esecuzione di un ciclo di test completo di Cloud Manager.
Per risolvere queste situazioni, la pipeline di produzione di Cloud Manager può essere eseguita in un emergenza modalità. Quando si utilizza questa modalità, i passaggi del test di sicurezza e prestazioni non vengono eseguiti; tutti gli altri passaggi, compresi eventuali passaggi di approvazione configurati, vengono eseguiti come nella normale modalità di esecuzione della pipeline.
La funzionalità di esecuzione della pipeline di emergenza viene attivata a livello di programma dai tecnici di successo del cliente.
Quando si avvia un’esecuzione della pipeline di produzione, se questa funzione è stata attivata, è possibile avviare l’esecuzione in modalità normale o di emergenza dalla finestra di dialogo, come illustrato nella figura riportata di seguito.
Inoltre, visualizzando la pagina dei dettagli di esecuzione della pipeline per un’esecuzione in modalità di emergenza, le breadcrumb nella parte superiore dello schermo mostrano un indicatore che indica che la modalità di emergenza è stata utilizzata per questa particolare esecuzione.
La creazione di un’esecuzione della pipeline in questa modalità di emergenza può essere eseguita anche tramite l’API o CLI di Cloud Manager. Per avviare un’esecuzione in modalità di emergenza, invia una richiesta PUT all’endpoint di esecuzione della pipeline con il parametro query ?pipelineExecutionMode=EMERGENCY
oppure, quando si utilizza CLI:
$ aio cloudmanager:pipeline:create-execution PIPELINE_ID --emergency
Utilizzo --emergency
può essere necessario aggiornare il flag al più tardi aio-cli-plugin-cloudmanager
versione.
La riesecuzione del passaggio di distribuzione di produzione è supportata per le esecuzioni in cui il passaggio di distribuzione di produzione è stato completato. Il tipo di completamento non è importante: la distribuzione potrebbe avere esito positivo (solo per i programmi AMS), essere annullata o non essere riuscita. Detto questo, si prevede che il caso d’uso principale sia quello in cui la fase di distribuzione della produzione non è riuscita per motivi transitori. La nuova esecuzione crea una nuova esecuzione utilizzando la stessa pipeline. Questa nuova esecuzione consiste in tre fasi:
Il passaggio di compilazione può essere etichettato in modo leggermente diverso nell’interfaccia utente per indicare che sta copiando gli artefatti, non sta ricostruendo.
Limiti:
Per identificare se un’esecuzione è un’esecuzione di nuova esecuzione, è possibile esaminare il campo trigger. Il suo valore sarà RE_EXECUTE.
Per attivare una nuova esecuzione, è necessario effettuare una richiesta PUT al collegamento HAL http://ns.adobe.com/adobecloud/rel/pipeline/reExecute
sullo stato del passaggio di distribuzione di produzione. Se questo collegamento è presente, l’esecuzione può essere riavviata da quel passaggio. Se è assente, l’esecuzione non può essere riavviata da quel passaggio. Nella versione iniziale, questo collegamento sarà sempre presente solo nel passaggio di distribuzione della produzione, ma le versioni future potrebbero supportare l’avvio della pipeline da altri passaggi. Esempio:
{
"_links": {
"http://ns.adobe.com/adobecloud/rel/pipeline/logs": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
"href": "/api/program/4/pipeline/1/execution?stepId=2983530",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/metrics": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/metrics",
"templated": false
},
"self": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530",
"templated": false
}
},
"id": "6187842",
"stepId": "2983530",
"phaseId": "1575676",
"action": "deploy",
"environment": "weretail-global-b75-prod",
"environmentType": "prod",
"environmentId": "59254",
"startedAt": "2022-01-20T14:47:41.247+0000",
"finishedAt": "2022-01-20T15:06:19.885+0000",
"updatedAt": "2022-01-20T15:06:20.803+0000",
"details": {
},
"status": "FINISHED"
Sintassi del collegamento HAL href il valore di cui sopra non è destinato ad essere utilizzato come punto di riferimento. Il valore effettivo deve sempre essere letto dal collegamento HAL e non generato.
Invio di un PUT la richiesta a questo endpoint darà luogo a un 201 in caso di esito positivo, l’organo di risposta sarà la rappresentazione della nuova esecuzione. È simile all’avvio di un’esecuzione regolare tramite l’API .