Le architetture moderne per i software, progettate per essere scalabili, portano con loro il bagaglio impegnativo della complessità.

Mentre il prodotto è ancora in fasce, e si sta cercando di validare le varie funzionalità, la complessità spesso viene considerata un male necessario, si perde del tempo a gestirla manualmente, perché la priorità è sul prodotto.

Questo atteggiamento purtroppo fa perdere più tempo di quanto ne fa guadagnare.

Le moderne tecniche CI/CD (Continuous Integration e Continuous Deployment) ci vengono incontro per risolvere il problema alla radice, anche se non sempre dimostrano l’elasticità necessaria a progetti con architetture custom.

Solitamente nei miei progetti scelgo soluzioni molto semplificate, fatte in casa, in grado di gestire autonomamente i deploy, per poi passare a sistemi proprietari quando e se occorreranno.

Questo dà agli sviluppatori e ad i devOps la confidenza e la sicurezza di lavorare in ambienti fortemente personalizzati, senza tonnellate di documentazione da studiare, con codice interno di cui si conoscono pregi e difetti.

La scrittura di simili tool, nella loro necessaria essenzialità, costruisce nel team una coscienza dell’architettura che sarà poi facile da tramandare ai nuovi entrati, e facile da trasferire su sistemi più complessi con l’aumentare delle necessità di deploy su reti sempre più complesse.

L’unica cosa da evitare è quindi non costruire questo piccolo traghetto che porta da zero a scalare a seconda dell’evoluzione dell’applicativo software.

La spiegazione del motivo è semplice da spiegare con la teoria delle code: se il primo elemento in una coda di trenta perde dieci minuti per bere un caffè perché deve farlo con la caffettiera, tutti perdono dieci minuti, se c’è una macchina automatica, tutti perdono un minuto.

Evitate di pensare che sia uno spreco di tempo automatizzare script frequenti, posponendolo a quando sarete meno impegnati. Ogni automazione renderà indietro il tempo speso. Speso bene.

Buona automazione a tutti.