6. Progetta lo sviluppo CI/CD per la distribuzione del componente Infrastruttura
Le differenze di infrastruttura tra i vari ambienti complicano lo sviluppo del software in esecuzione in un determinato ambiente. Le regole e le policy presenti (firewall, le autorizzazioni utente, l’accesso al database e altri componenti del livello di infrastruttura) devono essere gestite correttamente in una gestione della configurazione per assicurare sia la corretta esecuzione del software sia la corretta gestione dei vari componenti (items).
Occorre evitare per quanto possibile comportamenti manuali di distribuzione o di test, perchè l’infrastruttura o l’ambiente di test difficilmente potranno essere simulati nello stesso modo o in generale le azioni non potranno essere ripetute correttamente. La gestione della configurazione è una practice fondamentale per garantire la corretta e sana operatività (vedi processo Configuration Management: https://www.hrv-swiss.consulting/it/iso-iec-20000/ & https://www.hrv-swiss.consulting/it/01-itil-fnd/ ).
Dal momento che tutte queste attività sono molto complesse e comprendono molti passaggi, occorre ricordarsi di eseguire queste azioni nell’ordine corretto, con i parametri giusti; senza gestione della configurazione tutto questo potrà portare ad errori. L’infrastruttura deve essere definita nel codice, laddove possibile, per mitigare questi e altri problemi. L’infrastruttura potrà essere definita nel codice tramite tanti strumenti diversi, tra cui AWS CloudFormation, Terraform, Ansible, Puppet o Chef. Scrivere più pipeline per distribuire l’infrastruttura. Come per la scrittura del codice, è utile mantenere la distribuzione dell’infrastruttura modulare.
Se possibile, scomporre l’infrastruttura richiesta in sottoinsiemi disgiunti. I processi di Change e Configuration Management devono essere utilizzati all’unisono. Le pipeline CI/CD sono create per la distribuzione di codice. Queste pipeline sono in genere semplici da implementare poiché l’infrastruttura è già disponibile grazie al lavoro svolto in precedenza. In questa fase è importante prestare attenzione ai test, alla ripetibilità e alla capacità di ripristino da distribuzioni errate. La ripetibilità è la capacità di distribuire la stessa modifica più volte senza danneggiare il sistema.
Occorre che la distribuzione imposti lo stato di un sistema su una configurazione nota. Un esempio semplice di aggiornamento non ripetibile è l’aggiornamento di un file di configurazione tramite l’accodamento di dati. Questo principio va applicato anche all’aggiornamento dei database. Gli aggiornamenti dei database possono essere problematici e richiedono grande attenzione. È essenziale fare in modo che il processo di aggiornamento del database sia ripetibile e tollerante agli errori. Occorre eseguire dei backup prima di applicare le modifiche per poter eseguire un ripristino se necessario. Ci sono due modi generali per gestire questa situazione. Il primo è eseguire un rollback. Il secondo è utilizzare i flag delle funzioni e disattivare i flag necessari per reimpostare il sistema su uno stato corretto noto. Il rollback consente di distribuire lo stato corretto noto precedente in un ambiente in seguito al rilevamento di una distribuzione errata. Questa operazione deve essere pianificata fin dall’inizio.
Prima di iniziare a lavorare su un database, occorre eseguire un backup. Occorre assicurarsi di poter distribuire rapidamente la versione precedente del codice e testare il processo di rollback negli ambienti di test o staging con regolarità.
Maggiori informazioni al link del corso di DevOps FOundation: https://www.hrv-swiss.consulting/it/01-devops-fnd/
