The Twelve-Factor App

V. Build, release, esecuzione

Separare in modo netto lo stadio di build dall’esecuzione

Una codebase viene “trasformata” in deploy attraverso tre fasi:

Il codice diventa build, che combinata con le impostazioni diventa release.

Un’app twelve-factor definisce una separazione netta tra build, release ed esecuzione. Ad esempio, è impossibile effettuare dei cambiamenti del codice a runtime, dato che non c’è modo di propagare queste modifiche all’“indietro”, verso la fase di build.

I tool di deploy offrono tipicamente dei tool di gestione delle release, in particolare alcuni dedicati ad un rollback verso una release precedente. Ad esempio, Capistrano memorizza le varie release in una sotto-directory chiamata releases, in cui la release attuale non è che un symlink verso la directory della release attuale. Il comando di rollback permette di tornare indietro ad una certa release velocemente.

Ogni release dovrebbe inoltre possedere un ID univoco di rilascio, come ad esempio un timestamp (es. 2011-04-06-20:32:17) o un numero incrementale (es. v100). In un certo senso, la creazione di una release è una procedura “a senso unico” e una certa release non può essere modificata dopo la sua creazione. Qualsiasi cambiamento deve quindi prevedere una nuova release.

Una fase di build è sempre avviata da uno sviluppatore, non appena il codice viene modificato. Al contrario, l’esecuzione può essere anche gestita in modo automatico (si pensi al riavvio del server oppure ad un crash con successivo riavvio del processo). Ad ogni modo, una volta in esecuzione, la regola aurea è di evitare il più possibile (se non del tutto) modifiche che potrebbero rompere qualche equilibrio. Magari nel bel mezzo della notte, quando non c’è nessuno disponibile. La fase di build può essere sicuramente più “faticosa”, comunque, visto che possono verificarsi degli errori da risolvere prima di proseguire.