Implementare il codice deploy-your-code
Scopri come distribuire il codice nell’ambiente di produzione con le pipeline di Cloud Manager in AEM as a Cloud Service.
La distribuzione del codice nell’ambiente di staging e successivamente nell’ambiente di produzione avviene tramite una pipeline di produzione. L’esecuzione della pipeline di produzione è suddivisa nelle due fasi logiche seguenti:
- Distribuzione nell'ambiente di staging - Il codice viene generato e distribuito nell'ambiente di staging per test funzionali automatizzati, test dell'interfaccia utente, audit dell'esperienza e test di accettazione utente (UAT).
- Distribuzione nell'ambiente di produzione - Una volta convalidata la build nell'ambiente di staging e approvata per la promozione nell'ambiente di produzione, lo stesso artefatto di build viene distribuito nell'ambiente di produzione.
Solo la pipeline del codice full stack supporta il controllo del codice, i test funzionali, i test dell’interfaccia utente e l’audit dell’esperienza.
Processo di distribuzione deployment-process
Tutte le distribuzioni di Cloud Service seguono un processo continuo per garantire l’operatività continua. Per ulteriori informazioni, consulta Funzionamento delle implementazioni continue.
Distribuire il codice con Cloud Manager in AEM as a Cloud Service deploying-code-with-cloud-manager
Dopo aver configurato la pipeline di produzione includendo archivio, ambiente e ambiente di test, tutto è pronto per la distribuzione del codice.
-
Accedi a Cloud Manager all’indirizzo my.cloudmanager.adobe.com e seleziona l’organizzazione appropriata.
-
Nella console Programmi fare clic sul programma per il quale si desidera distribuire il codice.
-
Nella pagina Panoramica, nell'area di invito all'azione, fare clic su Distribuisci.
-
Nella pagina Distribuisci in produzione fare clic su Genera.
Il processo di build distribuisce il codice attraverso le tre seguenti fasi ordinate:
Fase di implementazione nell’ambiente di staging stage-deployment
La fase Distribuzione nell'ambiente di staging prevede i seguenti passaggi:
Per informazioni dettagliate sull'ambiente di compilazione, vedere Dettagli ambiente di compilazione.
Consulta Test di qualità del codice per informazioni dettagliate sul processo di test.
Fase di test dello staging stage-testing
La fase Test dello staging prevede i seguenti passaggi:
Vedere anche Test funzionali del prodotto.
Vedere anche Test funzionali personalizzati.
I test dell'interfaccia utente sono basati su Selenium e inclusi in un'immagine Docker per offrire flessibilità nel linguaggio e nei framework. Questo approccio consente di utilizzare Java e Maven, Node e WebDriver.io o qualsiasi framework o tecnologia basati su Selenium.
Vedi anche Test dell'interfaccia utente personalizzati.
Questo passaggio nella pipeline viene sempre eseguito e non può essere saltato. Quando si esegue una pipeline di produzione, viene incluso un passaggio di audit dell’esperienza dopo i test funzionali personalizzati che eseguono i controlli.
- Le pagine configurate vengono inviate al servizio e valutate.
- I risultati sono informativi e mostrano i punteggi e cosa è cambiato tra il punteggio corrente e quello precedente.
- Questo approfondimento e è utile per determinare l’eventuale introduzione di una regressione con la distribuzione corrente.
Consulta Informazioni sui risultati dell'audit dell'esperienza.
Fase di implementazione di produzione production-deployment
Il processo di distribuzione nelle topologie di produzione è leggermente diverso per ridurre al minimo l’impatto sui visitatori di un sito AEM.
Le distribuzioni di produzione seguono generalmente gli stessi passaggi descritti in precedenza, ma in modo continuativo. Questi passaggi includono:
- Distribuire i pacchetti AEM nel servizio Author.
- Scollegare
dispatcher1
dal load balancer. - Distribuire i pacchetti AEM in
publish1
e il pacchetto Dispatcher indispatcher1
. Svuotare la cache di Dispatcher. - Ripristina
dispatcher1
nel load balancer. - Quando
dispatcher1
torna in servizio, scollegaredispatcher2
dal load balancer. - Distribuire i pacchetti AEM in
publish2
e il pacchetto Dispatcher indispatcher2
. Svuotare la cache di Dispatcher. - Ripristina
dispatcher2
nel load balancer.
Questo processo continua fino a quando la distribuzione non raggiunge tutti gli editori e i Dispatcher nella topologia.
Timeout durante una distribuzione timeouts
I passaggi seguenti si interrompono se vengono lasciati in attesa del feedback dell’utente durante una distribuzione:
Riesecuzione di una distribuzione di produzione reexecute-deployment
In rari casi, i passaggi di distribuzione nell’ambiente di produzione possono non riuscire per motivi transitori. In questi casi, la riesecuzione del passaggio di distribuzione nell’ambiente di produzione è supportata a condizione che il passaggio di distribuzione nell’ambiente di produzione sia stato completato, indipendentemente dal tipo di completamento (ad esempio, annullato o non riuscito). La riesecuzione crea una nuova esecuzione utilizzando la stessa pipeline composta dai tre passaggi seguenti:
- Convalida: la stessa convalida che si verifica durante una normale esecuzione della pipeline.
- Build - Nel contesto di una riesecuzione, il passaggio di compilazione copia gli artefatti e non esegue effettivamente un nuovo processo di compilazione.
- Distribuzione di produzione - Utilizza la stessa configurazione e le stesse opzioni del passaggio di distribuzione di produzione in una normale esecuzione della pipeline.
In tali circostanze, in cui è possibile eseguire una riesecuzione, la pagina di stato della pipeline di produzione fornisce l’opzione Riesegui accanto a quella consueta di Scarica registro build.
Limitazioni limitations
- La riesecuzione del passaggio di distribuzione di produzione è disponibile solo per l’ultima esecuzione.
- La riesecuzione non è disponibile per le esecuzioni degli aggiornamenti push. Se l’ultima esecuzione è un aggiornamento push, non è possibile eseguirla nuovamente.
- Se l’ultima esecuzione non è riuscita in un qualsiasi punto precedente al passaggio di distribuzione nell’ambiente di produzione, non è possibile eseguirla nuovamente.
Riesecuzione dell’API reexecute-API
Oltre a essere disponibile nell’interfaccia utente, è possibile utilizzare l’API di Cloud Manager per attivare le riesecuzioni e identificare le esecuzioni attivate come riesecuzioni.
Attivare una riesecuzione reexecute-deployment-api
Per attivare una riesecuzione, effettuare una richiesta PUT al collegamento HAL https://ns.adobe.com/adobecloud/rel/pipeline/reExecute
sullo stato del passaggio di distribuzione di produzione.
- Se tale collegamento è presente, l’esecuzione può essere riavviata da quel passaggio.
- Se è assente, l’esecuzione non può essere riavviata da quel passaggio.
Questo collegamento è disponibile solo per il passaggio di distribuzione nell’ambiente di produzione.
{
"_links": {
"https://ns.adobe.com/adobecloud/rel/pipeline/logs": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
"templated": false
},
"https://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
"href": "/api/program/4/pipeline/1/execution?stepId=2983530",
"templated": false
},
"https://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"
La sintassi del valore href del collegamento HAL è solo un esempio. Il valore effettivo deve sempre essere letto dal collegamento HAL e non generato.
L’invio di una richiesta PUT a questo endpoint genera una risposta 201 in caso di esito positivo; il corpo della risposta è la rappresentazione della nuova esecuzione. Questo flusso di lavoro è simile all’avvio di un’esecuzione regolare tramite l’API.
Identificare un’esecuzione rieseguita identify-reexecution
Il sistema identifica le riesecuzioni impostando il campo trigger
sul valore RE_EXECUTE
.