Pensez-vous qu'il est correct de combiner la compilation, les tests et la publication de l'image dans un seul workflow, ainsi que d'ajouter des étapes pour le déploiement dans différents environnements?

Ce n’est pas toujours optimal. Bien que cette approche puisse être pratique pour de petits projets ou des builds de test locaux, combiner toutes les étapes en un seul workflow présente des inconvénients :

• Réduction de la flexibilité : Le déploiement dans différents environnements (dev, staging, production) nécessite des paramètres différents et souvent des droits d’accès différents. La fusion complique la gestion de ces différences.
• Dépendance à l’environnement : Si le déploiement dans un environnement échoue, toute la build est considérée comme échouée, même si la création de l’image et son test ont réussi.
• Difficulté de rollback : Le rollback du déploiement devient moins trivial, car il faut revenir en arrière sur tout le workflow.
• Augmentation du temps d’exécution : L’ensemble du pipeline prend plus de temps, ce qui ralentit le retour d’information pour les développeurs.
• Moins de scalabilité : À mesure que le projet grandit et que le nombre d’environnements de déploiement augmente, ce workflow devient encombrant et difficile à gérer.

Une pratique plus répandue et flexible consiste à diviser ces étapes :

1. Pipeline de build et test : Responsable de la compilation du code, des tests, de la création de l’image et de son stockage dans un registre d’artefacts (par exemple, Docker Registry, Nexus). Ce workflow s’exécute à chaque commit ou pull request.
2. Pipeline de déploiement : Workflow séparés pour déployer dans chaque environnement. Ils prennent l’image déjà construite et testée du registre d’artefacts et la déploient dans l’environnement cible. Ces workflows peuvent être lancés manuellement, selon un calendrier ou automatiquement après la réussite de l’étape précédente (par exemple, déploiement réussi en staging).

Cela permet :

• Obtenir un retour plus rapide sur la qualité du code (build & test).
• Déployer dans différents environnements de manière indépendante.
• Gérer plus flexiblement les paramètres de déploiement pour chaque environnement.
• Simplifier le processus de rollback.

Une exception pourrait être de petits projets pet ou des applications monolithiques avec un processus de déploiement simple, où les coûts liés à la séparation dépassent les bénéfices. Cependant, dans la majorité des environnements d’entreprise, diviser le workflow est une meilleure pratique.