Implementare il codice

Distribuzione del codice con Cloud Manager

Dopo aver configurato la pipeline di produzione (archivio, ambiente e ambiente di test), è possibile distribuire il codice.

1. Fai clic su Distribuzione da Cloud Manager per avviare il processo di distribuzione.

   

2. La Esecuzione della pipeline viene visualizzato lo schermo.

   Fai clic su Crea per avviare il processo.

   

3. Il processo di compilazione completo distribuisce il codice.

   Nel processo di creazione sono coinvolte le seguenti fasi:

   1. Implementazione fase
   2. Test della fase
   3. Distribuzione di produzione
   NOTA

   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:

   • Convalida: Questo passaggio assicura che la pipeline sia configurata per utilizzare le risorse attualmente disponibili, ad esempio che il ramo configurato esista, che gli ambienti siano disponibili.
   • Build & Unit Testing: Questo passaggio esegue un processo di compilazione containerizzato. Vedi Informazioni sull’ambiente di creazione per informazioni dettagliate sull’ambiente di creazione.
   • Scansione del codice: Questo passaggio valuta la qualità del codice dell'applicazione. Vedi Comprendere i risultati del test per informazioni dettagliate sul processo di test.
   • Distribuisci su Stage

   

   La Test della fase, prevede i seguenti passaggi:

   • Test di sicurezza: Questo passaggio valuta l'impatto sulla sicurezza del codice dell'applicazione nell'ambiente AEM. Vedi Comprendere i risultati del test per informazioni dettagliate sul processo di test.
   • Test delle prestazioni: Questo passaggio valuta le prestazioni del codice dell'applicazione. Vedi Comprendere i risultati del test per informazioni dettagliate sul processo di test.

   

   La Distribuzione di produzione, prevede i seguenti passaggi:

   • Domanda di approvazione (se attivato)
   • Pianificazione distribuzione produzione (se attivato)
   • Supporto CSE (se attivato)
   • Distribuzione in produzione

   

   NOTA

   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.

   

Timeout

I seguenti passaggi si interrompono se rimangono in attesa del feedback degli utenti:

Processo di distribuzione

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:

1. Cloud Manager determina se ogni artefatto è un pacchetto AEM o dispatcher.

2. 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.

   

   NOTA

   Questa funzione dovrebbe essere utilizzata principalmente da 1-1-1 clienti.

3. 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.

   NOTA

   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 .

4. L’artefatto del dispatcher viene distribuito a ciascun dispatcher come segue:

   1. Le configurazioni correnti vengono sottoposte a backup e copiate in una posizione temporanea
   2. Tutte le configurazioni vengono eliminate tranne i file immutabili. Per ulteriori informazioni, consulta Gestire le configurazioni del Dispatcher . Questo cancella le directory per garantire che non vengano lasciati indietro i file orfani.
   3. L’artefatto viene estratto nel 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.
   4. Apache esegue un test di configurazione. Se non viene rilevato alcun errore, il servizio viene ricaricato. Se si verifica un errore, le configurazioni vengono ripristinate dal backup, il servizio viene ricaricato e l'errore viene riportato a Cloud Manager.
   5. Ogni percorso specificato nella configurazione della pipeline viene invalidato o scaricato dalla cache del dispatcher.
   NOTA

   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.

5. 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.

   NOTA

   È 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.

Fase di implementazione a produzione

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:

1. Distribuisci pacchetti AEM per l’authoring.
2. Scollega dispatcher1 dal load balancer.
3. Distribuisci pacchetti AEM a publish1 e il pacchetto dispatcher a dispatcher1 in parallelo, svuota la cache del dispatcher.
4. Rimetti dispatcher1 nel load balancer.
5. Una volta che dispatcher1 è tornato in servizio, scollega dispatcher2 dal load balancer.
6. Distribuisci pacchetti AEM a publish2 e il pacchetto dispatcher a dispatcher2 in parallelo, svuota la cache del dispatcher.
7. Rimetti dispatcher2 nel load balancer.
   Questo processo continua fino a quando la distribuzione non raggiunge tutti gli editori e i dispatcher nella topologia.

Modalità di esecuzione della tubazione di emergenza

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.

Utilizzo della modalità di esecuzione della pipeline di emergenza

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

Esegui nuovamente una distribuzione di produzione

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:

1. Passaggio di convalida : si tratta essenzialmente della stessa convalida che si verifica durante una normale esecuzione della pipeline.
2. Passaggio della build: nel contesto di una nuova esecuzione, il passaggio della build sta copiando gli artefatti e non esegue effettivamente un nuovo processo di compilazione.
3. Passaggio di distribuzione di produzione : utilizza la stessa configurazione e le stesse opzioni del passaggio di distribuzione di produzione in una normale esecuzione della pipeline.

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:

• La riesecuzione del passaggio di distribuzione di produzione sarà disponibile solo all’ultima esecuzione.
• La riesecuzione non è disponibile per le esecuzioni di rollback.
• Se l’ultima esecuzione è un’esecuzione di rollback, non è possibile eseguirla nuovamente.
• Se l’ultima esecuzione è un’esecuzione di aggiornamento push, non è possibile eseguirla nuovamente.
• Se l’ultima esecuzione non è riuscita in un qualsiasi punto prima della fase di distribuzione della produzione, non è possibile eseguire nuovamente l’esecuzione.

Esegui nuovamente l’API

Identificazione di un’esecuzione di nuova esecuzione

Per identificare se un’esecuzione è un’esecuzione di nuova esecuzione, è possibile esaminare il campo trigger. Il suo valore sarà RE_EXECUTE.

Attivazione di una nuova esecuzione

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 .