Avantages d'une approche basée sur les troncs pour l'intégrité de l'environnement

Comme de nombreux développeurs le savent, une modification du code peut parfois créer un effet papillon (article d'American Scientist), lorsqu'un petit écart apparemment sans rapport déclenche une réaction en chaîne qui entraîne des résultats inattendus. Les développeurs doivent ensuite mener une enquête approfondie pour en découvrir la cause première.

Lorsque les scientifiques mènent une expérience, ils séparent les sujets testés en deux groupes : le groupe expérimental et le groupe témoin. L'intention est de rendre le groupe expérimental et le groupe témoin complètement identiques, à l'exception de ce qui est testé dans le cadre de l'expérience. Lorsqu'il se passe quelque chose dans le groupe expérimental qui ne se produit pas dans le groupe témoin, la seule cause peut être le produit testé.

Considérez les modifications d'un déploiement comme le groupe expérimental et considérez chaque environnement comme des groupes de contrôle distincts. Les résultats des tests effectués dans un environnement inférieur ne sont fiables que lorsque les commandes sont les mêmes que dans un environnement supérieur. Plus les environnements s'écartent, plus il y a de chances de découvrir des défauts dans les environnements supérieurs. En d'autres termes, si les modifications du code doivent échouer en production, nous préférons de loin qu'elles échouent d'abord en version bêta afin qu'elles ne soient jamais mises en production. C'est pourquoi tout doit être mis en œuvre pour assurer la synchronisation de chaque environnement, de l'environnement de test le plus bas à la production elle-même. C'est ce qu'on appelle l'intégrité environnementale.

L'objectif de tout processus CI/CD complet est de découvrir les problèmes le plus tôt possible. La préservation de l'intégrité de l'environnement en utilisant une approche basée sur les troncs peut pratiquement éliminer le besoin de correctifs. Dans un flux de travail basé sur des troncs, il est rare qu'un problème apparaisse pour la première fois dans l'environnement de production.

Dans une approche Gitflow, une fois qu'un correctif est déployé directement dans les environnements supérieurs, il est ensuite ajouté à la branche de développement. Cela préserve le correctif pour les versions futures. Cependant, le correctif a été développé et testé directement en fonction de l'état actuel de l'application. Même si le correctif fonctionne parfaitement en production, il est possible que des problèmes surviennent lorsqu'il interagit avec les nouvelles fonctionnalités de la branche de développement. Le déploiement d'un correctif pour un correctif n'étant généralement pas souhaitable, les développeurs passent plus de temps à essayer d'adapter le correctif à l'environnement de développement. Dans de nombreux cas, cela peut entraîner un endettement technique important et réduire la stabilité globale de l'environnement de développement.

Lorsqu'une défaillance survient dans un environnement, toutes les modifications sont annulées afin que l'environnement retrouve son état antérieur. Toute modification d'une base de code doit redémarrer le pipeline dès la première étape. Lorsqu'un problème survient dans l'environnement de production, le correctif doit également être appliqué à l'ensemble du pipeline. Le temps supplémentaire nécessaire pour parcourir les environnements inférieurs est généralement négligeable par rapport aux problèmes évités grâce à cette approche. Étant donné que l'objectif des environnements inférieurs est de détecter les erreurs avant qu'elles ne soient mises en production, le fait de contourner ces environnements par le biais d'une approche Gitflow constitue un risque inefficace et inutile.