Quando sviluppiamo un software lo facciamo in team: siamo cioè un gruppo di persone, tra ingegneri e sviluppatori, che vanno a contribuire allo sviluppo delle diverse parti del software. Isole in sé autonome che devono essere in grado di dialogare tra loro per funzionare al meglio.
Innanzitutto definiamo il concetto di continuous integration o integrazione continua.
Un esempio pratico?
Quando sviluppiamo un software lo facciamo in team: siamo cioè un gruppo di persone, tra ingegneri e sviluppatori, che vanno a contribuire allo sviluppo delle diverse parti del software.
Ad un certo punto però le diverse parti vanno assemblate, ovvero integrate tra loro affinché lavorino efficacemente insieme: vanno cioè allineate.
Ecco: la continuous integration esprime proprio quest’allineamento. Esso avviene di frequente - spesso "più volte al giorno"- e consiste nell’integrazione dagli ambienti di lavoro dei singoli sviluppatori verso un ambiente condiviso in cui risiede il software nel suo complesso.
Il concetto nacque originariamente nel contesto dell’Extreme Programming, come contromisura preventiva al problema dell'integration hell, (l’”inferno” dell'integrazione di porzioni di software sviluppati in modo indipendente su lunghi periodi di tempo e potenzialmente significativamente divergenti).
Nello sviluppo non continuous gli sviluppi delle diverse parti del software procedono indipendentemente per lungo tempo, ed è solo al momento dell’integrazione che gli eventuali (inevitabili) problemi emergono: il momento dell’integrazione diventava quindi la cartina tornasole degli errori di progettazione e/o sviluppo, cui era spesso macchinoso rimediare vista la distanza temporale trascorsa dall’inizio dello sviluppo.
Con la continuous integration si apre un nuovo scenario di sviluppo: ogni fase della produzione, dal piccolo commit di codice al test sino al rilascio di funzionalità cardine viene tracciata e corrisponde ad una certa “versione” del software.
Ogni modifica o integrazione ha cioè un numero identificativo ed è tracciata ogni informazione ad essa correlata: quando, come e da chi è stata lanciata.
Cosa ne deriva?
Tantissimi vantaggi per un codice di qualità:
La continuous delivery è la conseguenza intrinseca della continuous integration: se il software è continuamente e frequentemente integrato, allora è anche continuamente e frequentemente rilasciabile in produzione, ovvero pubblicabile online e visibile al cliente.
E’ questo un punto cardine della tecnologia agile, che anche noi in SAEP applichiamo con le dovute personalizzazioni: il software come abbiamo detto è diviso in parti e lavorazioni, ciascuna delle quali va frequentemente integrata con le altre e rilasciata in produzione.
Ogni modifica introdotta nel codice è potenzialmente rilasciabile a giro breve, senza più lunghi tempi di attesa tra sviluppo e messa in produzione delle modifiche.
In che termini lo sviluppo con continuous integration porta qualità nello sviluppo del software e in ultima istanza agli occhi del cliente finale anche non tecnico?
Nello sviluppo non agile e senza continuous delivery il giorno del rilascio corrispondeva al Giorno del Giudizio Universale.
Provate a pensarci: 3 mesi di sviluppo e 1 solo giorno in cui tutti i nodi possono potenzialmente venire al pettine.
Spaventerebbe chiunque, giusto?
Con la continuous delivery invece gli sviluppatori sono fisiologicamente vaccinati al rilascio: la release non è più il D-Day tanto temuto, ma solo una delle tante fasi del processo di sviluppo e continuo miglioramento del software.
Il software stesso non è più un monolite statico e difficilmente penetrabile, ma un complesso di parti di codice in sé autonome e tra loro cooperanti che vengono testate e fatte dialogare tra loro di continuo, permettendone un’ottimizzazione progressiva senza soluzione di continuità.
Con lo sviluppo software sotto capillare controllo, è molto più semplice pianificare obiettivi realistici e progressivi su un periodo di tempo concordato tra team di sviluppo e team cliente.
Gli obiettivi possono essere presidiati, le richieste integrative o i cambiamenti in corsa sono capillarmente tracciati, così come i loro impatti sull’integrazione con le altre funzionalità previste.
Questo consente di avere controllo anche su eventuali ritardi – non più subiti come conseguenze di meccanismi imprevedibili, ma come scelte consapevoli di eventuali cambi di direzione - sui tempi complessivi di sviluppo ed i relativi costi.
La combo continuous integration + continuous delivery sconfigge la paura del rilascio e apre la strada ad un’evoluzione del software in sostanza più rapida, controllata e di qualità rispetto al passato.
