Bash Only Deployment

Il mondo degli strumenti scelti per il deployment è drogato dalla presenza di “strumenti innovativi” che vengono spinti dai rispettivi produttori (anche se
open) come soluzione a tutti i problemi di deployment o provisioning. Si tratta per lo più di prodotti “nuovi”, partiti nell’ultima decade. La cosa strana è che in ambiente Unix{,-like} l’automazione è stata presente fin da subito e questi stessi problemi venivano risolti anche senza questi bisogno di questi nuovi strumenti, spesso usando semplicemente lo Shell scripting.

La mia tesi è che usando l’onnipresente Bash sia possibile ottenere gli stessi o migliori risultati rispetto all’uso degli strumenti nuovi. Chiarmente, usando questo approccio, ci sono delle differenze:

  • La Bash non offre tutte le astrazioni di questi “strumenti innovativi”, ma non introduce nemmeno indirezioni o inutili astrazioni che ti obbligano a debuggare i problemi su due livelli.
  • La Bash “non ha un modulo/ricetta/plugin” per ogni problema di provisioning, ma non ti obbliga nemmeno a doverti scrivere un plugin per poter lanciare quell’unico ultimo commando che ti manca per finire il lavoro.
  • Se usi la Bash non ha *un* sito corporate che ti offre una estensiva documentazione di tutti i comandi per il deployment o il provisioning, ma non sei nemmeno limitato nel numero di risorse che posso contenere la soluzione al tuo problema.

La verità vera è che, alla fine (tolti i fronzoli), questi “strumenti innovativi”, sotto sotto, richiedono al sistema operativo di fare le stesse cose che potrebbe fare la Bash.

D’altra parte sia chiaro che io non voglio convincere nessuno, se sei uno che preferisce usare questi “strumenti innovativi” perché: 1) pensi che “siano nati per questo scopo”, 2) credi che tu non possa fare meglio, 3) consideri la Bash un linguaggio inefficace. Se pensi queste queste cose allora il talk non fa per te, non ne otteresti nessun beneficio.

Se invece, come me pensi che imparare a fare “Bash-Only Deployment” ti possa abilitare a:

  • capire cosa sta succedendo sotto
  • ridurre il tempo di debugging
  • darti la possibiltà di scegliere lo strumento “innovativo” solo quando effettivamente ti porta vantaggio

Allora ti consiglio di venire. Seguendo questo talk potrai scoprire quali sono le astuzie che mi hanno permesso di re-ingegnerizzare il sistema di deployment di un mostruoso e-commerce scritto in simil-Enterprise Java. Questo lavoro ha contribuito ad abbassare la trasformare la frequenza di deployment da “facciamo un deploy ogni 3 mesi” ad “stiamo portando in produzione con nuove feature ogni due giorni”.

Tutti i dettagli sulle demo live fatte durante la presentazione sono su GitHub.