Seguendo il trend dei must-have, per essere un team cutting edge non può certamente mancare un buon flow automatizzato o semi per il deploy.

Attualmente usiamo diverse strategie per il deploy in quanto lavorando con molti clienti ognuno con i rispettivi tech stacks e SLA requirements, talvolta dobbiamo adattarci. Questo significa dover passare da FTP a SCP, da WGET a Mina, da Ansible a git push.

Diversamente, per i progetti che hostiamo nella nostra infrastruttura, stiamo via via definendo gli step da replicare per avere un buon e resiliente workflow.

Il mio stack ideale dovrebbe fare la build generando un pacchetto per l’OS come un .rpm o un .deb opportunamente nominato che segua le convenzioni sul naming per poi essere deployato da un repo APT o YUM privato, sui vari application servers.

Questo stack richiede una macchina di build/CI ed una per il repo APT o YUM. Probabilmente over engineered per la maggior parte dei casi, ma senz’altro offre una flessibilità eccezionale e una sicurezza di primo livello.

Il workflow a cui puntiamo prevede una pipeline per la build ed una per il deploy.

La build si occuperà ad esempio di installare i vendor, processare gli assets e versionarli e creare una tarball. La pipeline di deploy si potrebbe occupare di scaricare la tarball, scompattarla, settare i cron, spawnare le job queue e fare il warmup della cache.

Sono step poco codificati nel nostro ambiente, quello IT, e spesso i concetti e le procedure si sovrappongono creando funzionalità borderline non idempotenti e poco efficaci.

La cornerstone per costruire un buon flow è saper valutare bene le esigenze ed i costi e saperne misurare l’impatto anche quando va tutto bene, perché si sa, quando una cosa funziona non ci si pongono più domande. Invece, è importante saper analizzare e monitorare i flussi quando viene introdotta una nuova tecnologia, per permetterci di percepire il miglioramento o peggioramento.

Altro metodo di analisi più che valido sono i WTFs/minute.