Automazione e governance delle pipeline end-to-end (parte 2 di 2)

Questo blog post è la seconda parte di una serie che ha l'obiettivo di presentare una serie di sfide che le aziende devono affrontare nello sviluppo di integrazioni moderne e come è possibile affrontarle facilmente con SnapLogic. È possibile trovare laprima parte di questa serie qui.

In questo articolo, imparerete come la piattaforma SnapLogic vi aiuterà a

• Eseguire controlli di qualità con test unitari e conformità alle politiche.
• gestire la richiesta di fusione
• promuovere le modifiche alla produzione e informare le parti interessate

Creazione della richiesta di unione

Dopo che l'integratore ha identificato una soluzione per risolvere i problemi, come ultimo passo, l'integratore deve integratore creerà una Richiesta di unione in GitLab per chiedere che le modifiche vengano unite al ramo Prod dal ramo Master.

Nota: questo post del blog si sposta direttamente dal ramo Master al ramo Prod, promuovendo di fatto le risorse dall'ambiente di sviluppo all'ambiente di produzione. Questo non riflette necessariamente le migliori pratiche per le strutture e le politiche organizzative di tutti i clienti.

Controlli delle richieste di unione

Dopo la creazione della richiesta di unione, GitLab eseguirà automaticamente una pipeline Pipeline CI/CD che comprende due lavori; eseguiTest e eseguiControlli. Per far sì che questo funzioni, il ingegnere CI/CD (fare riferimento alla parte 1 di questa serie) ha creato un file di configurazione CI/CD di GitLab. Il file di configurazione CI/CD (come si vede qui sotto) esegue i seguenti compiti:

• eseguiTest
  • Funziona solo per le richieste di unione
  • Esegue la prima fase chiamata test
  • Esegue lo script runTests.sh
• eseguiControlli
  • Funziona solo per le richieste di unione
  • Esegue la seconda fase chiamata controlli
  • Esegue lo script runChecks.sh
• eseguirePromozione
  • Viene eseguito solo per le modifiche al ramo Prod
  • Esegue la terza fase chiamata promuovere
  • Esegue lo script runPromotion.sh

 

Nota: sebbene questo blog post utilizzi le funzionalità di GitLab per il CI/CD, è importante capire che, grazie al supporto REST e JSON della piattaforma SnapLogic, la creazione di lavori simili in altri strumenti come Azure DevOps, GitHub, Bamboo, ecc. segue la stessa logica e gli stessi aspetti tecnici. 

Come indicato, il ingegnere CI/CD ha configurato solo due lavori da eseguire alla creazione di una richiesta di unione: runTest e runCheckse saranno eseguiti in quest'ordine. Analizziamo innanzitutto cosa succede quando il primo lavoro (runTest) e viene eseguito lo script runTests.sh (mostrato di seguito). Innanzitutto, viene eseguita un'attività innescata da SnapLogic, denominata attività RunUnitTests. Quindi controlla se il risultato è stato positivo o negativo e, in base al risultato, passa o fallisce l'intera pipeline CI/CD.

Il task RunUnitTests esegue una pipeline chiamata RunUnitTests, come mostrato di seguito. Questa pipeline esegue le seguenti operazioni

1. Elenca tutte le pipeline del progetto interessato.
2. Filtra le pipeline che non sono soggette a test unitari.
3. Per ogni pipeline, esegue la pipeline 01_UnitTestingTemplate utilizzando lo snap Esegui pipeline (etichettato come Esegui test).
4. Filtra i risultati testati con successo
5. Confronta il numero di test riusciti con il numero di test totali e crea una risposta per il cliente, indicando il numero di test completati o falliti.

Come detto in precedenza, la pipeline RunUnitTests determina le pipeline da testare e invia i risultati dei test al client, ma non esegue i test stessi. Invoca invece la pipeline 01_UnitTestingTemplate per ogni pipeline da testare. Questa pipeline può essere vista di seguito. Essa esegue le seguenti operazioni.

1. Reads the expected results (parameterized as <Pipeline_name>_result.json) – in our case from the file CustomerToSalesforce_result.json (see previous chapters). 
2. Read the input test data (parameterized as <Pipeline_name>_input.json) – in our case from the file CustomerToSalesforce_input.json (see previous chapters). 
3. Executes the target Pipeline (parameterized as <Pipeline_name>_target) – in our case from the file CustomerToSalesforce_target (see previous chapters) using the Pipeline Execute Snap (labelled as Test Pipeline)
4. Utilizza il Diff Snap per confrontare i risultati attesi con i risultati effettivi basati sulla pipeline eseguita (CustomerToSalesforce_target con i dati di test CustomerToSalesforce_input.json). Il Diff Snap mostra ogni riga come eliminata, inserita, modificata o non modificata. Solo se tutte le righe sono immodificate (vista etichettata come Success), il test sarà considerato superato.
5. Restituisce il risultato del singolo test alla pipeline padre (RunUnitTests)

Il processo e le pipeline di cui sopra sono stati concordati dal Responsabile del test e ingegnere CI/CD e dall'intero team di integrazione, in base ai requisiti e alle politiche di ACME. Potrebbero esserci anche altri test, come i test di performance e i test funzionali, che non rientrano nell'ambito di questo post.

Nota: i risultati dei test unitari e dei controlli di qualità saranno visibili più avanti in questo post.

Se tutti i test passano e lo script runTests.sh ha successo, la fase e il lavoro successivi (runChecks) della configurazione CI/CD di GitLab vengono eseguiti, invocando lo script runChecks.sh. Lo script runChecks è stato concordato tra il ingegnere CI/CD e il responsabile della responsabile della sicurezza. Il responsabile della sicurezza richiede l'applicazione di una serie di regole e politiche alle pipeline e alle altre risorse SnapLogic che devono essere messe in produzione. Queste politiche potrebbero includere

• Convenzioni di denominazione su Pipeline, etichette Snap o altre proprietà
• Scatti proibiti
• Impostazioni vietate negli snap

Per ACME, il responsabile della sicurezza fornisce le seguenti politiche (definite in formato JSON)

[

    {

        "classe": "com-snaplogic-snaps-transform-recordreplay",

        "condizionale": false

    },

    {

        "classe": "com-snaplogic-snaps-binary-aesencrypt",

        "condizionale": vero,

        "impostazioni": [

            {

                "nome": "cipherMode",

                "allowedValue": "CBC"

            }

        ]

    }

]

In effetti, l'intenzione di questa politica è di

• Evitare l'uso di Record Replay Snap nell'organizzazione di produzione. ACME è un'azienda sottoposta a pesanti controlli e non può permettere che i dati dei clienti vengano salvati in un archivio persistente. 
• Evitare l'uso della funzione Crittografia AES Snap se l'impostazione della modalità di cifratura è non impostata su CBC. ACME ha una politica di sicurezza aziendale che prevede l'utilizzo della modalità CBC per la crittografia.

Questo criterio significa che qualsiasi snap di Record Replay o qualsiasi snap di AES Encrypt (che non abbia CBC come modalità di cifratura) non sarà consentito in produzione. Per ottenere questo risultato, lo script runChecks.sh chiamerà un'attività innescata di SnapLogic per verificare le pipeline interessate rispetto al documento dei criteri e non accettare il lavoro se non rispetta i criteri. Lo script runChecks.sh è visibile di seguito.

L'attività RunQualityChecks invocata dallo script runChecks.sh esegue la pipeline RunQualityChecks che si può vedere di seguito. La sua logica assomiglia a quella della pipeline RunUnitTests mostrata in precedenza.

1. Elenca tutte le pipeline del progetto interessato.
2. Per ogni pipeline, esegue la pipeline 01_QualityCheck utilizzando lo snap di esecuzione della pipeline (etichettato come Check Quality).
3. Calcolato il numero di pipeline andate a buon fine
4. Confronta il numero di controlli riusciti con il numero di controlli totali e crea una risposta per il client, contenente il numero di controlli completati e non riusciti e il motivo per cui i test sono falliti.

Analogamente alle pipeline per i test unitari, la pipeline RunQualityChecks determina le pipeline per le quali eseguire i controlli e invia i risultati dei controlli al client, ma non esegue i controlli di qualità stessi. Invoca invece la pipeline 01_QualityCheck per ogni pipeline soggetta a controlli di qualità. Questa pipeline è visibile qui sotto. Essa esegue le seguenti operazioni.

1. Legge la Pipeline sottoposta a controlli di qualità
2. Estrae tutti gli snap utilizzati nella pipeline. Poiché SnapLogic è una piattaforma nativa JSON, gli snap e le loro proprietà sono semplicemente oggetti JSON.
3. Legge e analizza il documento JSON della politica ACME fornito dal responsabile della sicurezza. responsabile della sicurezza.
4. Unire gli snap con gli snap del criterio per assicurarsi che vengano controllati solo gli snap che hanno una corrispondenza nel criterio. 
5. Controlla se uno snap è consentito o meno
6. Controlla se uno Snap è consentito o meno in modo condizionato (ad esempio, se le impostazioni sono consentite).
7. Crea una risposta alla pipeline genitore con i risultati

Se i controlli di qualità passano (dopo che i test unitari sono stati superati), la richiesta di unione è pronta per essere approvata.

Approvazione della richiesta di unione

Il Architetto sarà ora responsabile della revisione della richiesta di unione. Se le modifiche sono sensate e se i test unitari automatici e i controlli di qualità sono stati superati, l'Architetto Architetto approverà e unirà la richiesta. Inizierà aprendo la Merge Request (vista sotto) appena sollevata per vedere il riepilogo del suo contenuto

• Il titolo della richiesta di unione è stato impostato come titolo del singolo commit Git.
• La richiesta di unione contiene un singolo commit
• Il singolo commit contiene tre modifiche: 1 file modificato e 2 aggiunte.
• È in corso una pipeline CI/CD di richiesta di unione (indicata dall'icona blu di avanzamento).
• C'è un'opzione per unire la richiesta quando la pipeline ha avuto successo 

Prima di esaminare le modifiche alla Merge Request, la pipeline si completa con il seguente riepilogo delle fasi/lavori. Come si può notare, la fase eseguiTasti è stato completato con successo. Tuttavia, il successivo runChecks non è andato a buon fine. Possiamo analizzare entrambi per capire cosa è successo.

Per prima cosa, apriamo il file runTests per vedere il riepilogo. Come si può vedere qui sotto, i test sono stati completati con successo.

In secondo luogo, esaminiamo il riepilogo del lavoro runChecks. A differenza del riepilogo di runTests, questo lavoro non è completo. Dice che i controlli di qualità non sono stati completati con successo. Delle tre pipeline controllate (CustomerToSalesforce, CustomerToSalesforce_target e CustomerToSalesforce_test), una non è andata a buon fine: la pipeline CustomerToSalesforce_target. Se si fa riferimento al progetto di tale pipeline mostrato in precedenza in questo post, si può notare che abbiamo utilizzato un Record Replay Snap per aiutarci durante lo sviluppo. Tuttavia, in base alle politiche fornite dal responsabile della sicurezzaquesto non è consentito in produzione.

Il Architetto può ora sincronizzarsi con l Integratore per esaminare il problema, se non è già stato rilevato dall'integratore. Integratore attraverso un avviso. Poiché il processo di modifica è già stato trattato in questo blog post, ora assumeremo che sia stata eseguita una nuova iterazione con un commit modificato e una Merge Request aggiornata, rimuovendo il Record Replay Snap. L'output del lavoro runChecks è ora come di seguito.

Infine, il Architetto può esaminare le modifiche utilizzando due metodi. Nel primo metodo, può esaminare le modifiche alla struttura JSON tra le due versioni della pipeline CustomerToSalesforce, comprendendo quali snap e proprietà sono stati modificati. In secondo luogo, può utilizzare la pipeline SnapLogic Confronta pipeline per ottenere un confronto visivo tra la vecchia e la nuova versione della pipeline. Come si vede nell'immagine sottostante, si può notare che è stato aggiunto uno snap di esecuzione della pipeline per astrarre la logica di trasformazione e di validazione dalla pipeline stessa, in modo da consentire i test unitari.

Dopo aver esaminato le modifiche e aver confermato il superamento dei test unitari e dei controlli di qualità, l'Architetto Architetto è d'accordo nell'approvare le modifiche e nell'unire la richiesta di fusione. Di conseguenza, le ultime modifiche sono state trasferite nel ramo Prod.

Promozione alla produzione + biglietto risolto

Come ultimo passo nell'ambito dello scenario ACME end-to-end, le nuove modifiche alla pipeline unite al ramo Prod dovrebbero essere promosse automaticamente al ramo SnapLogic Produzione di SnapLogic. Come già detto, il passaggio diretto da un ramo di sviluppo a uno di produzione potrebbe non essere l'approccio migliore, poiché in genere si consiglia di utilizzare un ambiente di staging, come un ambiente di QA o di test. Tuttavia, per gli scopi di questo blog post, stiamo passando dall'ambiente di sviluppo a produzione direttamente. Quando le modifiche sono state spostate in produzionevogliamo anche chiudere automaticamente il ticket, evidenziando come è stato risolto. Tutti questi passaggi sono stati automatizzati come da accordo tra il ingegnere CI/CD e Operazioni.

Facendo riferimento al capitolo sui controlli delle richieste di fusione, la pipeline di GitLab aveva un terzo lavoro chiamato eseguirePromozione. Come ripasso, esegue le seguenti operazioni:

• eseguirePromozione
• • Viene eseguito solo per le modifiche al ramo Prod
  • Esegue la terza fase chiamata promuovere
  • Esegue lo script runPromotion.sh

Come l'azione di fusione della richiesta di unione intrapresa dall' Architetto ha spostato le modifiche nel ramo Prod, il task runPromotion verrà eseguito automaticamente. Quando viene eseguito, il flusso completo della richiesta di unione appare come di seguito. I passaggi seguenti sono visibili nell'immagine.

1. È stata creata una richiesta per spostare le modifiche tra il ramo Master e quello Prod.
2. Una pipeline CI/CD è passata (si trattava di eseguire test unitari e controlli di qualità)
3. La richiesta è stata approvata e accorpata dal Architetto
4. Un'altra pipeline CI/CD è passata (questa è la pipeline di promozione)

Controlliamo l'output del job di promozione finale che esegue lo script runPromotion.sh. Come si può vedere qui di seguito, il job ha promosso con successo le 3 pipeline alla Produzione org. Una di esse è stata aggiornata, mentre le altre due non esistevano e hanno dovuto essere create. Se si trattasse di una nuova serie di pipeline sviluppate, tutti i risultati sarebbero stati Created.

In che modo i gasdotti sono passati dalla fase di sviluppo alla produzione produzione? Diamo un'occhiata al contenuto dello script runPromotion.sh. Esegue l'attività RunPromotion Triggered Task e passa il messaggio di commit del commit effettivo, che nel nostro caso include il numero di riferimento del ticket JIRA.

L'attività innescata RunPromotion richiama la pipeline RunPromotion, come si può vedere di seguito. Esegue le seguenti operazioni.

1. Legge lo spazio corrente (ACMEissues) nello spazio di sviluppo (dove risiedono le nuove pipeline) e il progetto corrente (CRM_MIGRAZIONE)
2. Se quello spazio e quel progetto non esistono nella produzione li crea
3. Elenca tutte le pipeline del progetto sorgente e richiama la pipeline 01_PromotePipeline per ogni pipeline, usando lo snap Esegui pipeline (etichettato come Promuovi pipeline).
4. Crea una risposta al client se la pipeline 01_PromotePipeline ha successo.
5. Transita e aggiorna il ticket JIRA correlato (estratto utilizzando un'espressione regolare dal messaggio di commit del commit GitLab)
6. Invia un'e-mail a Operazioni con il risultato

Come detto, per ogni pipeline presente nel progetto sorgente, viene richiamata 01_PromotePipeline. Questa pipeline, visibile qui sotto, esegue le seguenti operazioni

1. Legge la Pipeline dal progetto sorgente (nella cartella sviluppo ambiente)
2. Lo crea nel progetto di destinazione (nella cartella di produzione se non esiste
3. Oppure lo aggiorna nel progetto di destinazione (nel file di produzione se esiste
4. Formatta una risposta da restituire alla pipeline padre

Con questo, le modifiche sono state promosse alla produzione e il ticket JIRA è stato chiuso. Il messaggio di posta elettronica riportato di seguito è stato inviato automaticamente al reparto Operazionicon un link al ticket aggiornato.

Come parte di SnapLogic, il problema è stato spostato nella cartella Fatto viene aggiunto automaticamente un commento al ticket, indicando quali Pipeline sono state coinvolte nella risoluzione del problema.

Sintesi

Questo blog post ha dimostrato come un'azienda ACME fittizia e i suoi personaggi possano utilizzare in modo efficiente strumenti di automazione, versioning e helpdesk di terze parti per fornire una gestione end-to-end del ciclo di vita di SnapLogic Pipeline. 

Considerando che si tratta di un post lungo, ecco gli argomenti e i processi trattati in questo blog post. 

Con la piattaforma SnapLogic è possibile

• Acquisizione automatica degli errori della pipeline di produzione
• Creazione automatica di ticket helpdesk con informazioni dettagliate sull'errore.
• Chiedere agli integratori e agli architetti di lavorare in modo collaborativo per controllare le versioni e rivedere il lavoro su più ambienti SnapLogic.
• Automatizzare i test unitari e i controlli di qualità per aderire alle politiche aziendali.
• Automatizzare le migrazioni e le promozioni per garantire che le risorse giuste vengano spostate negli ambienti SnapLogic dell'azienda.
• Sfruttare una piattaforma nativa REST e JSON aiuta ad automatizzare e governare ogni aspetto del ciclo di vita.

Le personas, i processi, le policy e gli strumenti descritti in questo blog post possono essere facilmente modificati per soddisfare le esigenze di qualsiasi azienda. Se la vostra azienda non ha ancora accesso alla piattaforma di integrazione intelligente SnapLogic, registratevi per una prova gratuita oggi stesso!