Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Dans quelle mesure CI/CD les processus sont-ils complètement différents ?
Les pipelines CI/CD utilisent un *flux de travail moderne basé sur des troncs*, dans lequel les développeurs fusionnent de petites mises à jour fréquentes dans une branche principale (ou *tronc*) créée et testée via la partie CD du pipeline. CI/CD Ce flux de travail a remplacé le flux de travail *Gitflow*, dans lequel les branches de développement et de publication sont séparées par un calendrier de publication. Dans de nombreuses organisations, Gitflow est toujours une méthode populaire de contrôle de version et de déploiement. Cependant, il est désormais considéré comme un héritage et il peut être difficile de l'intégrer dans un CI/CD pipeline.
Pour de nombreuses organisations, la transition d'un flux de travail Gitflow à un flux de travail basé sur des troncs a été incomplète, ce qui les a empêchées de migrer complètement vers le CI/CD. D'une manière ou d'une autre, leurs pipelines finissent par s'accrocher à certains vestiges de l'ancien flux de travail, coincés dans un état de transition entre le passé et le présent. Passez en revue les différences entre les flux de travail Git, puis découvrez comment l'utilisation d'un flux de travail existant peut affecter les éléments suivants :
+ [Intégrité environnementale](environment-integrity.md)
+ [Versions](releases.md)
+ [Sécurité](security.md)
Pour faciliter l'identification des vestiges d'un flux de travail Git existant dans une configuration moderne, comparons [Gitflow](#gitflow-approach) à l'approche moderne basée sur les [troncs](#trunk-based-approach).
## Approche Gitflow
L'image suivante montre un flux de travail Gitflow. L'approche Gitflow utilise plusieurs branches pour suivre plusieurs versions différentes du code en même temps. Vous planifiez la publication des mises à jour d'une application dans le futur pendant que les développeurs travaillent toujours sur la version actuelle du code. Les référentiels basés sur des troncs peuvent utiliser des indicateurs de fonctionnalité pour y parvenir, mais ils sont intégrés par défaut à Gitflow.
![\[Un flux de travail Gitflow avec des branches relatives aux fonctionnalités, au développement, à la publication et aux correctifs\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
L'une des conséquences de l'approche Gitflow est que les environnements applicatifs sont généralement désynchronisés. Dans une implémentation standard de Gitflow, les environnements de développement reflètent l'état actuel du code tandis que les environnements de préproduction et de production restent figés sur l'état de la base de code de la version la plus récente.
Cela complique les choses lorsqu'un défaut apparaît dans l'environnement de production, car la base de code dans laquelle les développeurs travaillent ne peut pas être fusionnée avec la production sans exposer des fonctionnalités inédites. Gitflow gère cette situation en utilisant un correctif. Une branche de correctif est créée à partir de la branche de version, puis déployée directement dans les environnements supérieurs. La branche du correctif est ensuite fusionnée avec la branche de développement afin de maintenir le code à jour.
## Approche basée sur le tronc
L'image suivante montre un flux de travail basé sur des troncs. Dans un flux de travail basé sur des troncs, les développeurs créent et testent des fonctionnalités localement dans une branche de fonctionnalités, puis fusionnent ces modifications dans la branche principale. La branche principale est ensuite intégrée aux environnements de développement, de préproduction et de production, de manière séquentielle. Des tests unitaires et d'intégration ont lieu entre chaque environnement.
![\[Un flux de travail basé sur des troncs avec des branches de fonctionnalités et une branche principale.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
Grâce à ce flux de travail, tous les environnements utilisent la même base de code. Il n'est pas nécessaire de créer une branche de correctif pour les environnements supérieurs, car vous pouvez implémenter des modifications dans la branche principale sans exposer les fonctionnalités inédites. La branche principale est toujours supposée stable, exempte de défauts et prête à être libérée. Cela vous permet de l'intégrer en tant que source pour un CI/CD pipeline, qui peut automatiquement tester et déployer votre base de code dans tous les environnements de votre pipeline.
# 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](https://www.americanscientist.org/article/understanding-the-butterfly-effect) (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 CI/CD processus 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.
# Profitez des avantages d'une approche basée sur les troncs
L'une des raisons pour lesquelles un correctif est souvent nécessaire est que, dans un flux de travail existant, l'état de l'application sur laquelle les développeurs travaillent peut contenir plusieurs fonctionnalités inédites qui ne sont pas encore en production. L'environnement de production et l'environnement de développement ne sont synchronisés que lorsqu'une version planifiée est publiée, puis ils recommencent immédiatement à diverger jusqu'à la prochaine version planifiée.
Il est possible de planifier des sorties dans le cadre d'un CI/CD processus complet. Vous pouvez retarder la mise en production du code en utilisant des indicateurs de fonctionnalité. Cependant, un CI/CD processus complet permet une plus grande flexibilité en rendant inutiles les publications planifiées. Après tout, le mot « *continu* » est un mot clé du CI/CD, ce qui suggère que les modifications sont publiées dès qu'elles sont prêtes. Évitez de maintenir un environnement de publication distinct qui est presque toujours désynchronisé avec les environnements de test inférieurs.
Si un pipeline n'est pas entièrement CI/CD, la divergence entre les environnements supérieur et inférieur se produit généralement au niveau de la branche. Les développeurs travaillent dans une branche de développement et gèrent une branche de publication distincte qui est mise à jour uniquement au moment d'une publication planifiée. Lorsque la branche de publication et la branche de développement divergent, d'autres complications peuvent survenir.
Outre le fait que les environnements ne sont pas synchronisés, lorsque les développeurs travaillent sur le volet développement et s'habituent à un état d'application bien supérieur à celui de la production, ils doivent se réajuster à l'état de production chaque fois qu'un problème survient. L'état de la branche de développement pourrait comporter de nombreuses caractéristiques avant la production. Lorsque les développeurs travaillent dans cette branche tous les jours, il est difficile de se souvenir de ce qui est mis en production et de ce qui ne l'est pas. Cela augmente le risque que de nouveaux bogues soient introduits lors de la correction d'autres bogues. Il en résulte un cycle apparemment infini de correctifs qui prolongent les délais et retardent le lancement des fonctionnalités pendant des semaines, des mois, voire des années.
# Avantages en matière de sécurité d'une approche basée sur les troncs
Un CI/CD processus complet fournit une approche entièrement automatisée basée sur une source unique de vérité pour le déploiement. Le pipeline possède un point d'entrée unique. Les mises à jour logicielles entrent dans le pipeline dès le début et sont transmises telles quelles d'un environnement à l'autre. Si un problème est découvert à un stade quelconque du pipeline, les modifications de code qui le corrigent doivent suivre le même processus et commencer dès la première étape. La réduction du nombre de points d'entrée dans un pipeline réduit également les possibilités d'introduction de vulnérabilités dans le pipeline.
De plus, comme le point d'entrée est le point le plus éloigné possible de l'environnement de production, cela réduit considérablement le risque que des vulnérabilités atteignent la production. Si vous implémentez un processus d'approbation manuel dans un pipeline CI/CD complet, vous pouvez toujours autoriser ou non la prise de décision quant à la promotion des modifications dans l'environnement suivant. Le décideur n'est pas nécessairement la même personne qui déploie les changements. Cela permet de séparer les responsabilités du déployeur des modifications de code de celles de l'approbateur de ces modifications. Cela permet également à un responsable d'organisation moins technique de jouer le rôle d'approbateur.
Enfin, le point d'entrée unique vous permet de limiter l'accès en écriture à la console d'interface utilisateur (UI) de l'environnement de production à quelques utilisateurs, voire à aucun. En réduisant le nombre d'utilisateurs autorisés à apporter des modifications manuelles dans la console, vous réduisez le risque d'événements de sécurité. La capacité de gérer manuellement la console dans l'environnement de production est bien plus nécessaire dans les flux de travail existants que dans le cadre d'une approche CI/CD automatisée. Ces modifications manuelles sont plus difficiles à suivre, à examiner et à tester. Ils sont généralement réalisés pour gagner du temps, mais à long terme, ils ajoutent une dette technique importante au projet.
Les problèmes de sécurité de la console ne sont pas nécessairement causés par des acteurs malveillants. La plupart des problèmes qui se produisent dans la console sont accidentels. L'exposition accidentelle à la sécurité est très courante et a entraîné l'essor du modèle de sécurité Zero Trust. Ce modèle part du principe que les accidents de sécurité sont moins probables lorsque même le personnel interne dispose d'un accès aussi restreint que possible, ce que l'on appelle également les autorisations du *moindre privilège.* La préservation de l'intégrité de l'environnement de production en limitant tous les processus à un pipeline automatisé élimine pratiquement le risque de problèmes de sécurité liés à la console.