Caratteristiche e principi della metodologia Twelve-Factor App
Twelve-Factor App abbraccia totalmente le metodologie agili descritte finora. Le applicazioni scritte seguendo questo approccio ottengono direttamente tutti i principali vantaggi del mondo DevOps, tra cui dichiarazione chiara di requisiti, configurazioni e funzionalità, al fine di favorire l’ingresso di nuovi sviluppatori, adattabilità all’installazione su infrastrutture cloud, possibilità di implementare il concetto di Continuous Deployment.
Twelve-factor App può in generale essere applicata durante un qualsiasi tipo di sviluppo software, ed è indipendente dal linguaggio di programmazione scelto o da eventuali servizi esterni (ad esempio database).
Principi Twelve-Factor App
I dodici fattori o principi su cui basare lo sviluppo sono i seguenti.
I dodici fattori o principi su cui basare lo sviluppo sono i seguenti:
- Codebase
- Dipendenze
- Configurazione
- Backing Service
- Build, release, esecuzione
- Processi
- Binding delle Porte
- Concorrenza
- Rilasciabilità
- Parità tra Sviluppo e Produzione
- Log
- Processi di Amministrazione
Descriviamoli più nel dettaglio.
1. Codebase
Con il termine codebase si intende l’insieme del codice sorgente dell’applicazione. È fondamentale che sia presente un’unica codebase, ossia un unico repository (letteralmente “deposito”). All’interno del repository è possibile rilasciare vari deployments, ossia diverse istanze dell’applicazione: un deployment può ad esempio essere un nuovo rilascio effettuato in seguito ad un aggiornamento dell’applicazione, o una singola versione posseduta in locale da un singolo sviluppatore. Nell’ottica di poter gestire con ordine tutte le istanze all’interno della codebase è fondamentale utilizzare un sistema per il versionamento di ogni istanza.
2. Dipendenze
La gestione delle dipendenze, quindi l’utilizzo di eventuali librerie esterne, deve avvenire in maniera molto precisa. Esse devono essere isolate e dichiarate: isolate perché non devono essere contenute nella codebase, ma devono essere recuperate in real time da repository esterni; a tal proposito, devono essere dichiarate in una sorta di “contratto” (file manifest) con l’applicazione. Ciò consente ad ogni sviluppatore di avere una visione chiara e precisa di tutte le dipendenze.
3. Configurazione
La “configurazione” di un servizio consiste in tutto ciò che può cambiare tra i vari deployments. Possono essere elementi di configurazione le credenziali per accesso a servizi esterni, i parametri di connessione al db o generiche variabili utilizzate all’interno dell’applicazione. È molto importante dichiarare questi parametri come “variabili d’ambiente”, e non come costanti all’interno del codice, in quanto quest’ultimo può non cambiare tra diversi deployments, al contrario delle configurazioni.
4. Backing Service
Per Backing Service si intende un servizio di terze parti utilizzato dall’applicazione, come ad esempio un database, un server di autenticazione o un servizio di code/messaging.
Nel Twelve Factor App un servizio locale ed un servizio di terze parti vengono considerati e trattati in ugual modo come risorse. I parametri di connessione a queste risorse devono essere dichiarati nel file di configurazione, in modo da poter passare da una risorsa ad un’altra equivalente senza apporre modifiche al codice.
parametri di configurazione sarebbe possibile passare da un’autenticazione su Amazon ad una su Twitter.
Ciò garantisce una maggiore tolleranza ai guasti in quanto, in caso di malfunzionamento di una risorsa, è possibile “scollegarla” e utilizzarne un’altra utile al nostro scopo.
5. Build, release, esecuzione
Come si ottiene un deployment? La risposta è nel quinto fattore, cioè mediante tre fasi: build, release ed esecuzione. La prima fase fa una “costruisce” (build) il codice presente nella codebase, creando un eseguibile con all’interno le dipendenze associate. La seconda fase associa alla build tutte le configurazioni specifiche di quel rilascio, creando una release. A questo punto l’applicazione può essere lanciata: si arriva alla terza fase, la fase di esecuzione.
La metodologia twelve factor prevede una netta separazione tra queste tre fasi, che devono inoltre verificarsi necessariamente in questo ordine. Non sono previste quindi ad esempio modifiche del codice nella fase di esecuzione (modifiche a runtime): infatti in caso di modifiche si dovrà rieffettuare la fase di build e ripartire con i passi descritti.
6. Processi
L’applicazione quando è in stato di esecuzione esegue uno o più processi per servire le richieste in ingresso. È importante che ogni processo non conservi variabili temporanee o non utilizzi meccanismi di cache, e che le operazioni eseguite dal processo siano quanto più atomiche possibile. “I processi Twelve Factor sono inoltre stateless (senza stato) e share-nothing (non condividono nulla con altri processi)”. Ogni dato persistente deve essere memorizzato in un backing service.
7. Binding delle Porte
Al contrario di molte applicazioni che per essere in stato di esecuzione hanno bisogno di un “contenitore” (tipicamente un server web), le applicazioni Twelve Factor sono autocontenute e non necessitano di contenitori per esporre i propri servizi. Esse effettuano una assegnazione delle porte (binding) specifica per determinati servizi, fornendo una URL completa sulla quale esporre il servizio stesso. In questo modo possono fungere da backing service per altre applicazioni.
8. Concorrenza
Il concetto di concorrenza riprende il fattore che riguardava i processi. Sappiamo che un’applicazione in stato di esecuzione è composta da uno o più processi. È possibile implementare la concorrenza istanziando più processi. Occorre innanzitutto fare una divisione logica, assegnando ogni processo ad un tipo di lavoro, per implementare una sorta di scalabilità orizzontale. In seguito, a seconda del carico di lavoro, ogni tipo di processo può essere istanziato nuovamente, aumentando il numero di processi attivi e scalando verticalmente l’applicazione.
9. Rilasciabilità
La rilasciabilità è una qualità che deve essere posseduta dai processi dell’applicazione. Con il termine rilasciabilità si intende che essi potranno essere avviati o stoppati al bisogno su richiesta, in maniera “agile”, mirando a velocizzare quanto più possibile le fasi di deploy e di avvio dell’applicazione, ed a rendere quanto più possibile la stessa tollerante ad errori improvvisi.
10. Parità tra Sviluppo e Produzione
Nello sviluppo DevOps in generale esistono due ambienti nettamente separati in cui viene rilasciato il software, ossia l’ambiente di sviluppo e quello di produzione. Solitamente esistono delle sostanziali differenze tra questi due ambienti riguardanti le tempistiche di rilascio, gli stack di tecnologie utilizzate e gli sviluppatori coinvolti.
Il principio di questo fattore è quello di limitare al massimo queste differenze.
11. Log
Nelle classiche applicazioni solitamente i log vengono salvati in un apposito file su disco. In un’applicazione Twelve Factor è necessario trattare i log come uno stream di eventi sequenziali. Durante lo sviluppo in locale questo stream può essere restituito sullo standard output, così da renderlo di rapida consultazione. Mentre l’applicazione è in esecuzione, invece, è bene indirizzare lo stream verso sistemi appositi per la gestione dei log, che permetteranno la consultazione degli stessi, di statistiche ed errori in tempo reale.
12. Processi di Amministrazione
L’ultimo fattore riguarda i cosiddetti processi di amministratore: quei processi che vengono effettuati saltuariamente per la gestione o la manutenzione dell’applicazione (come la migrazione di un database o l’esecuzione di script all’interno dell’ambiente). Secondo questo approccio questi processi dovrebbero essere eseguiti prima dell’avvio dell’applicazione. Per poter invece intervenire in tempo reale anche quando l’applicazione è in esecuzione, occorrerebbe lavorare su una nuova release, che condivida lo stesso codice e le stesse configurazioni della versione attiva. Dopo gli interventi ed una fase di test, si procederà con l’avvio della release “aggiornata”, che sostituirà la precedente.
