IX. Rilasciabilità
Massimizzare la robustezza con avvii veloci e shutdown graduali
I processi di un'applicazione twelve-factor sono rilasciabili, cioè possono essere avviati o fermati senza problemi al momento del bisogno. Questa caratteristica ovviamente facilita le procedure di scaling, deploy rapido della codebase o cambi dei file di configurazione.
I processi dovrebbero inoltre ambire a minimizzare i tempi di avvio. Idealmente, un processo impiega pochi secondi dal tempo di lancio al momento in cui tutto è pronto per ricevere nuove richieste. Dei tempi brevi di avvio inoltre forniscono una maggiore agilità in fase di release; il tutto a vantaggio della robustezza dell'applicazione, dato che il process manager può così muoversi agevolmente verso un'altra macchina fisica, se necessario.
I processi dovrebbero inoltre terminare in modo tutt'altro che brusco, quindi graduale, in caso di ricezione di un segnale SIGTERM dal process manager. Per un'applicazione web, la giusta terminazione di un processo viene ottenuta quando si cessa innanzitutto di ascoltare sulla porta dedicata del servizio (evitando quindi di ricevere altre richieste), permettendo poi di terminare le richieste esistenti ed infine di concludere la fase di terminazione in modo definitivo.
Per un processo worker, invece, la fase di terminazione più adatta vede il ritorno del job corrente alla coda. Ad esempio, su RabbitMQ il worker può inviare un NACK; su Beanstalkd, il job viene automaticamente rimandato in coda nel caso in cui il worker si disconnette. I sistemi basati su lock come Delayed Job prevedono una "messa in sicurezza" prima di rilasciare il loro lock sul record del job attuale. Basandosi su questo modello risulta implicito che tutti i vari job sono di tipo reentrant, obiettivo raggiungibile wrappando il risultato in una transazione o rendendo l'operazione idempotente.
I processi dovrebbero, inoltre, essere "robusti nei confronti di situazioni di crash improvviso", cosa che si verifica ad esempio in caso di problemi a livello di hardware sottostante. Nonostante questa seconda evenienza si verifichi meno frequentemente di una chiusura con SIGTERM, può comunque succedere. L'approccio raccomandato, in questi casi, è l'uso di un sistema robusto di code, come Beanstalkd, che rimanda il job in coda in caso di timeout o disconnessione. Ad ogni modo, una buona applicazione twelve-factor deve poter gestire senza problemi le terminazioni inaspettate. Il Crash-only design porta questo concetto alla sua logica conclusione.