DevOps: come implementare il processo?
Abbracciare la metodologia DevOps e la sua filosofia è il primo passo per costruire il lavoro in modo “diverso”. Ma come si implementa concretamente il processo?
Il processo DevOps
In un precedente articolo ho illustrato il mindset che bisogna avere per strutturare un processo DevOps: la teoria è fondamentale per poter dare vita a un lavoro di squadra guidato da buone pratiche di sviluppo, ma soprattutto di rilascio.
Ovviamente, se conoscere il mindset è un passo importantissimo, bisogna poi essere in grado di strutturare il processo con i giusti strumenti, legati anche alle tecnologie scelte per il proprio lavoro.
In 20tab abbiamo sviluppato un template open source che ci permette di fare setup di progetti in pochissimi secondi e, fin dal primo istante e dal primo commit, di avere delle pipeline di CI/CD, oltre a consentirci di fare deploy in produzione.
Come abbiamo già visto, avere feedback rapidamente ci dà la possibilità di modificare e migliorare il software con estrema velocità: questo significa rispondere velocemente alle esigenze di mercato. Significa anche soddisfare il cliente al momento del bisogno, quindi dare un servizio di altissima qualità.
Le prime fasi
In 20tab non abbiamo una figura dedicata al processo DevOps, per cui abbiamo dovuto trovare un’alternativa che mantenesse alta la qualità del processo e soprattutto che non creasse dei blocchi nelle attività.
Ma partiamo dall’inizio.
Per poter soddisfare le aspettative che si hanno nella realizzazione di un software è fondamentale che ogni membro del team conosca gli obiettivi di questo progetto e la roadmap da seguire.
- Per quanto riguarda gli obiettivi, è necessaria una buona analisi degli impatti. Questa ci permette di pianificare le attività e ottimizzare le risorse. Maurizio Delmonte ce ne parla in un articolo molto interessante.
- Per la roadmap invece ci affidiamo ad un ottimo strumento di analisi delle attività: lo User Story Mapping, di cui Gabriele Giaccari espone la tecnica in questo secondo articolo.
Questi due primi passi, insieme ad una fase di design, ci aiutano ad effettuare un backlog di attività che includono anche task di setup di progetto. Una volta avviata la fase di implementazione delle nostre funzionalità, abbiamo bisogno di poter fare dei deploy e rilasciare costantemente nuove feature.
Nel nostro processo utilizziamo generalmente 3 ambienti diversi per i rilasci:
- Development: il nostro ambiente di sviluppo, che corrisponde ad una versione del progetto in alpha testing. Generalmente è un ambiente dove i membri del team di sviluppo e i referenti tecnici del cliente possono effettuare i primi test. Ogni piccola integrazione viene rilasciata in questo ambiente quotidianamente.
- Integration: si tratta dell’ambiente dove vengono rilasciate le funzionalità in seguito a revisioni periodiche. Le integrazioni in questo ambiente sono meno frequenti e legate soprattutto alle revisioni degli sprint. Generalmente le nuove funzionalità vengono rilasciate dopo ogni ciclo, che dura due settimane circa.
- Production: questo è l’ambiente di produzione, del tutto identico ad integration. I rilasci su di esso avvengono solo a seguito dell’esplicita accettazione da parte del committente.
Il workflow
Come si può notare dalla figura precedente, che rappresenta il workflow appena descritto, le prime sei fasi sono facilmente automatizzabili. Vediamo cosa avviene in particolare ad ogni fase.
- Source: questo è il momento in cui le nuove funzionalità implementate vengono aggiunte al repository git.
- Test: la pipeline di Continuous Integration esegue i test in modo automatico. Questo ci permette di rilasciare codice protetto da eventuali bug, mentre i test automatici ci permettono di monitorare eventuali regressioni.
- Build: viene creata una build dell’applicazione, quindi un’immagine Docker che sarà usata per i nostri rilasci.
- Development: se i test e le build automatiche passano i check, allora non ci sono problemi tecnici e quindi il codice può essere revisionato. Questo vuol dire che segue un’approvazione delle nuove modifiche.
- User Acceptance Test: il nuovo codice viene subito rilasciato sul sistema di sviluppo. In seguito sarà effettuata una review delle nuove funzionalità dal punto di vista utente, con un controllo di qualità, e se tutto va bene allora sarà dato l’ok per il rilascio sul sistema di staging (il nostro Integration).
- Staging: non è altro che il rilascio sul sistema Integration. Si tratta di un passaggio necessario per verificare che tutto ciò che è stato approvato in sviluppo non abbia subito regressioni di alcun tipo e che soddisfi i requisiti per andare in produzione. In caso contrario potrebbe creare problemi al software in produzione, con conseguenze dirette sul business legato ad esso.
- Production: mandare le nuove funzionalità in produzione deve essere una scelta non automatica, ma dettata dalle richieste del business. Se tutte le fasi precedenti sono andate a buon fine allora, quando vorremo, potremo integrare il nostro nuovo codice con il software già usato dai nostri utenti, con la sicurezza di non aver creato disagi di alcun tipo.
Il template di 20tab
Per automatizzare tutto il processo abbiamo deciso di creare un template open source che strutturasse i nostri progetti secondo le nostre tecnologie e i nostri standard. E che, ovviamente, rispettasse tutti i principi dei processi Agile e DevOps.
Il template che utilizziamo si compone di 3 blocchi principali:
- un servizio che chiamiamo Backend: si tratta di un progetto Django che generalmente offre le API rest e l’interfaccia al Database;
- un servizio che chiamiamo Frontend: generalmente per noi è un progetto sviluppato in React (javascript o typescript);
- un orchestratore: si tratta di un repository dove vengono salvate le configurazioni di kubernetes, necessarie per tutti gli ambienti che useremo.
La struttura è ovviamente legata alle tecnologie che usiamo duranto il nostro sviluppo, ma l’approccio usato prescinde da esse.
Qui trovi il modello da cui partire per creare i tuoi progetti: seguendo la guida passo passo, riuscirai a costruire un prodotto funzionante in pochissimi minuti. Ovviamente sarà lo scheletro che conterrà tutto ciò che sarà necessario al tuo nuovo software.
Ho spiegato tutti i passaggi anche in un video:
Se per programmare usi il nostro stesso stack tecnologico, allora potrai usare questo template così com’è.
E se usi linguaggi differenti? L’approccio che abbiamo visto qui vale anche con essi. Essendo una procedura, può essere slegata dalla tecnologia.
La cosa importante da tenere a mente è che usando un buon mindset, creando una buona collaborazione col team e osservando le best practices della programmazione allora si può ottenere un buon processo DevOps. Anche senza avere una figura dedicata a quello scopo.
