Servizi e applicazioni web
Lo stesso schema di processo adottato per i dipositivi embedded è stato utilizzato anche sui servizi e applicazioni web.
In questo caso l’ecosistema .NET è più ricco e offre funzionalità che sono da considerarsi standard “de-facto”, come ad esempio nuget. Siamo andati quindi ad aggredire aspetti più legati al processo di rilascio, configurazione e qualità degli artefatti. In particolare, la parte di deploy necessita di configurazioni molto più sofisticate rispetto agli apparati embedded e impone vincoli sia tecnologici che contrattuali.
Il primo passo è stato quello di descrivere e implementare la metodologia con cui una nuova release di un qualsiasi componente viene portata a bordo del server. Per fare questo abbiamo creato dei building block che utilizzano Ansible e la relativa descrizione dello stato atteso sul server, ovvero abbiamo creato un repository che descrive per ogni cliente, la lista di componenti e relative versioni che devono essere installate. Questo si traduce in una sorta di “contratto” col cliente, che molto spesso decide di mantenere la governance della sua infrastruttura.
Per poter ottenere questo “contratto” è importante che esista un flusso certificato che produce e versiona ogni pacchetto/componete. È in questo momento che abbiamo introdotto la cultura DevOps, in cui ogni team è responsabile sia di sviluppare il software che di preoccuparsi di come esso sarà installato in campo. Il paradigma implementato è quello di Infrastructure as code, ovvero ogni componente dichiara, sfruttando i building block descritti sopra, come deve essere installato sul server e quali tipo di configurazioni specifiche o condivise servono. Per esempio, un microservizio X, insieme al sorgente del codice, potrà contenere la descrizione del runner (IIS, NGINX, Docker) gli eventuali asset privati (immagini, ecc.), le configurazioni globali (connessione al DB, indirizzi di altri servizi) e gli eventuali parametri privati (chiavi di accesso, feature toggle, …).
Per evitare errori umani nella creazione dei pacchetti/componenti abbiamo introdotto le pipeline di continuous integration, in questo modo possiamo certificare e rendere riproducibile la creazione di un componente. Per realizzare questo abbiamo usato TeamCity come strumento di Continuous Integration e Nexus come unico repository da cui è possibile scaricare un componente da installare. Ovviamente, per cercare di evitare regressioni, le pipeline di Continuous Integration eseguono unit test ed eventuali integration tests.