Pensi che sia corretto combinare la build, i test e la pubblicazione dell'immagine in un unico workflow, oltre ad aggiungere passaggi per il deployment in diversi ambienti?

Questo non è sempre ottimale. Sebbene questo approccio possa essere comodo per piccoli progetti o build di test locali, unire tutte le fasi in un unico workflow presenta degli svantaggi:

• Riduzione della flessibilità: Il deployment in ambienti diversi (dev, staging, produzione) richiede parametri diversi e spesso permessi di accesso diversi. Unire tutto complica la gestione di queste differenze.
• Dipendenza dall'ambiente: Se il deployment in uno degli ambienti fallisce, tutta la build viene considerata fallita, anche se la creazione dell'immagine e i test sono andati a buon fine.
• Difficoltà di rollback: Tornare indietro con il deployment diventa meno semplice, poiché bisogna ripristinare tutto il workflow.
• Aumento del tempo di esecuzione: L'intero pipeline richiede più tempo, rallentando il feedback agli sviluppatori.
• Meno scalabilità: Con l'aumentare del progetto e del numero di ambienti di deployment, questo workflow diventa ingombrante e difficile da gestire.

Una pratica più diffusa e flessibile è suddividere queste fasi:

1. Build & Test Pipeline: Si occupa di compilare il codice, eseguire i test, creare l'immagine e salvarla nel registro degli artefatti (ad esempio, Docker Registry, Nexus). Questo workflow si avvia ad ogni commit o pull request.
2. Deployment Pipelines: Workflow separati per il deployment in ogni ambiente. Prendono l'immagine già creata e testata dal registro degli artefatti e la distribuiscono nell'ambiente di destinazione. Questi workflow possono essere avviati manualmente, programmati o automaticamente dopo il completamento con successo della fase precedente (ad esempio, deployment riuscito in staging).

Questo permette:

• Feedback più rapido sulla qualità del codice (build & test).
• Deployment indipendente in diversi ambienti.
• Gestione più flessibile dei parametri di deployment per ogni ambiente.
• Semplificazione del processo di rollback.

Un'eccezione può essere rappresentata da piccoli pet-project o applicazioni monolitiche con un processo di deployment semplice, dove i costi di suddivisione superano i benefici. Tuttavia, nella maggior parte degli ambienti aziendali, suddividere il workflow rappresenta una best practice.