Il concetto alla base `e quello di evitare by design l’esistenza di forme di conoscenza che risiedano in un luogo diverso da quello del repository del progetto.
Sostanzialmente anche l’ultimo arrivato una volta ricevuto l’accesso ai sorgenti deve poter accedere a tutte le informazioni essenziali per la gestione del ciclo di vita del progetto senza doversi far affiancare da un qualche esperto.
Ogni forma di divulgazione deve essere messa in campo con un approccio difensivo che non si basa sulla speranza di vedere onorate le guidelines da parte degli interessati ma di forzarne il rispetto adottando ogni strumento possibile. Questo per limitare gli errori di interpretazione e la creativit`a degli individui pi`u pigri.
Sostanzialmente significa rendere automatizzate le principali fasi di un pro- getto quali ad esempio:
Il recupero delle dipendenze.
La compilazione dei sorgenti in un artefatto. Il testing.
La posa in opera della soluzione elaborata.
Anche l’informazione su quali sono gli esecutori di queste procedure automatizzate e come devono essere configurati deve essere centralizzata allo stesso modo e richiedendo il minor lavoro manuale possibile.
Un’altra tematica degna di interesse `e quella delle autorizzazioni. La fase di rilascio finale tipicamente richiede il possesso delle chiavi di accesso agli ambienti remoti. Questa informazione `e quanto di pi`u prezioso ci sia associato ad un progetto online! In questo caso quindi `e desiderabile un processo inverso, in cui le operazioni sono ad appannaggio di tutti, ma la conoscenza ad esse associata `e segreta.
Esistono poi delle informazioni che non necessariamente sono traducibili in operazioni ma che comunque `e bene che siano condivise e storicizzate. Un esempio di queste sono la lista dei bug noti, le discussioni tra i membri del team e la documentazione del progetto.
L’implementazione di un workflow che soddisfacesse queste specifiche `e stato reso possibile sostanzialmente da 4 strumenti fondamentali:
GitLab ´E la soluzione che abbiamo scelto per avere un repository remoto GIT, una gestione tipo Wiki per la documentazione, una gestione di issues per tracciare i bug aperti e le richieste di features ed uno strumento centralizzato per l’esecuzione di pipelines di CI/CD.
Vagrant ´E lo strumento che grazie all’uso della virtualizzazione permette di ricrea- re sulla workstation dello sviluppatore un ambiente di lavoro ottimale tagliato specificatamente per il progetto e dotato di tutti gli strumenti da esso richiesti. Package Managers Sono usati per recuperare i tool necessari per la gestione del ciclo
di vita del progetto (principalmente compilatori e strumenti di testing). Sono usati inoltre per gestire il recupero e l’installazione delle dipendenze software del progetto.
Ne sono stati coinvolti di diversi, a seconda della fase specifica del progetto e dell’ambito di impiego.
Task Runners Sono usati per eseguire delle procedure seguendo un copione scriptato (che viene versionato alla pari dei sorgenti del progetto).
Sono stati usati sostanzialmente in ogni fase del progetto dalla compilazione, al testing, al build ed al rilascio.
Developer Build Script
1
Feature Request6
Testing5
Preview8
Trigger Pipeline Execution Clienti Clienti Issues Manager Issues Manager Feature Branch Feature Branch3
CheckoutAmbiente di lavoro virtualizzato
4
Sviluppo2
New branch Master Branch Master Branch7
Merge +9
Build10
Archive Artifact Deploy Script11
Deploy Staging Env Production EnvServer GitLab aziendale Agente di esecuzione pipelines CI/CD
Figura 3.1: Il nostro workflow di produzione del software.
1. I clienti segnalano attraverso la chat con l’operatore bug e richieste di nuove implementazioni. Queste vengono inserite nella sezione Issues di GitLab in modo da conservarne uno storico ed organizzare il lavoro in base alle loro priorit`a. In seguito viene fatta una valutazione sulla riproducibilit`a dello scenario descritto, il fatto che rientri o no nell’assistenza ordinaria e se vi sia budget a sufficienza per gestirle. L’interfaccia permette di inserire commenti, referenziare snippet di codice ed eventualmente iniziare lo sviluppo della patch creando un branch dedicato. 2. Lo sviluppo dell’attivit`a non deve mai avvenire sul branch master se non in raris-
simi casi in cui si `e certi della velocit`a dello sviluppo e del fatto che questo non introduca bug. Come linea di principio generale ogni nuovo sviluppo deve es- sere portato avanti su un branch dedicato in linea con la metodologia Feature Branch (1.1.2.3)
3. Lo sviluppatore prepara la sua working copy locale per avviare il processo di svi- luppo. I sorgenti recuperati contengono un file descriptor (vagrantfile) che pro- cessato dal tool Vagrant permette di creare un ambiente di lavoro virtualizzato
basato su Virtual Box che rispecchia l’ambiente in cui verr`a rilasciato il sistema una volta completato. Questo ambiente ha a bordo tutti gli strumenti necessari per proporre un’esperienza di sviluppo efficiente.
4. Lo sviluppatore modifica i sorgenti operando dal sistema operativo host usando il suo IDE di preferenza. Noi abbiamo usato NetBeans.
5. Il sistema Vagrant esegue in background un network share tra macchina fisica e quella virtualizzata in modo che i sorgenti siano automaticamente accessibili anche da dentro la macchina guest. Grazie ai server ed alle configurazioni fatte in fase di creazione di tale ambiente `e possibile eseguire il sistema in anteprima con un apprezzabile livello di fedelt`a visto che la macchina `e stata appositamente preparata per rassomigliare il pi`u possibile a quella di produzione.
6. Allo stesso modo con cui sono stati provisionati i servizi di sistema che permettono l’esecuzione del progetto, a bordo della macchina guest sono disponibili i framework e gli strumenti necessari per eseguire le procedure di test.
Abbiamo scelto di eseguire le procedure manualmente in questa fase e non automa- ticamente prima del rilascio per poter avere rilasci immediati (a volte siamo certi che la modifica introdotta non pu`o introdurre regressioni e sarebbe penalizzante dover aspettare l’intera esecuzione del ciclo prima di andare online).
L’altro motivo che ci ha spinto ad agire in questa fase `e che `e difficile scrivere pro- cedure di test perfette. Alcune (rare) volte accade che il test fallisca per un parti- colare glitch avvenuto durante la sua esecuzione senza che a questo episodio vi sia un bug reale alle spalle. Volevamo evitare che un falso negativo prevenisse il rilascio quindi abbiamo deciso di gestire la fase di test manualmente.
7. Una volta che il lavoro sul feature branch `e completo e testato pu`o essere fuso con quello sul master.
Nel caso lo sviluppo della feature si sia protratto per del tempo e nel frattempo siano state introdotte nuove commit sul master, era a carico dello sviluppatore eseguire delle pull periodiche in modo da mantenere i due filoni progettuali il meno discostanti possibile.
Quando questo metodo viene eseguito con diligenza il merge `e quasi sempre una operazione indolore.
8. I sorgenti del progetto contengono un file descrittore (.gitlab-ci.yml) che istrui- sce il gestore delle pipelines di CI/CD di GitLab su come comportarsi a fronte della comparsa di una nuova versione sul repository.
Le nostre pipelines sono progettate per avviarsi ad ogni merge sul filone master quindi l’operazione appena fatta scatena questa esecuzione.
In particolare l’esecuzione viene portata avanti da un agente detto runner che si avvale della tecnologia della containerizzazione per eseguire le procedure in isolamento e senza lasciare scorie sul sistema.
9. Il runner istanzia un container di base idoneo per il task che deve eseguire. Ad esempio per il repository ’app’ viene selezionato un container che ha gi`a a bordo il motore di esecuzione Node.js; vengono quindi recuperati tutti i tool necessari per la fase di build (tramite il suo package manager npm) ed avviata la produzione dell’artefatto con un task anch’esso scriptato insieme ai sorgenti.
10. Il frutto della fase di build viene collezionato dal sistema per 2 scopi: (a) Rendere l’artefatto disponibile in altre fasi (es. quella di deployment) (b) Rendere dispo- nibile l’artefatto attraverso l’interfaccia web di GitLab per un eventuale ispezione manuale e per storicizzare le varie release.
11. Ora viene nuovamente istanziato un container che ha gli strumenti a bordo specifici per effettuare il rilascio sulla piattaforma remota.
Esistono diverse soluzioni per fare un versamento di file su un host remoto, quali ad esempio FTP, RSYNC o SSH.
Questi tool vengono scelti in base al fatto che serva o no eseguire anche delle procedure di maintenance o sia sufficiente solo fare un trasferimento di file.
Le credenziali necessarie per la connessione vengono impostate tramite l’interfac- cia web di GitLab ed iniettate a runtime dentro al runner sottoforma di variabili d’ambiente.
In questo modo gli script di rilascio (che sono versionati tra i sorgenti)
possono essere divulgati perch´e non contengono informazioni sensibili.
Le nostre pipelines sono programmate per effettuare il deployment automatica- mente sull’ambiente di staging, mentre su quello di produzione bisogna entrare nell’interfaccia web di GitLab ed avviare manualmente l’attivit`a.
In questo modo ad ogni merge troviamo sull’ambiente di staging la versione che sta per diventare quella futura ed abbiamo modo di effettuare eventuali ultime prove prima di procedere col rilascio sull’ambiente pubblico.