Une introduction aux meilleures pratiques CI / CD

L’intégration continue, la livraison et le déploiement, connu collectivement sous le nom de CI / CD, fait partie intégrante de développement moderne visant à réduire les erreurs lors de l’intégration et du déploiement tout en augmentant la vitesse du projet. CI / CD est une philosophie et un ensemble de pratiques souvent complétées par un outillage robuste qui met l’accent sur les tests automatisés à chaque étape du pipeline de logiciels. En intégrant ces idées dans votre pratique, vous pouvez réduire le temps nécessaire pour intégrer les modifications d’une version et tester minutieusement chaque modification avant de la passer en production.

L’IC / DC présente de nombreux avantages potentiels, mais une mise en œuvre réussie nécessite souvent beaucoup d’attention. Décider exactement comment utiliser les outils et les modifications dont vous pourriez avoir besoin dans vos environnements ou processus peut s’avérer difficile sans essais et erreurs de grande ampleur. Cependant, même si toutes les implémentations seront différentes, le respect des meilleures pratiques peut vous aider à éviter les problèmes courants et à obtenir des améliorations plus rapidement.

Dans ce guide, nous présenterons quelques conseils de base sur la mise en œuvre et la maintenance d’un système CI / CD afin de mieux répondre aux besoins de votre organisation. Nous couvrirons un certain nombre de pratiques qui vous aideront à améliorer l’efficacité de votre service CI / CD. N’hésitez pas à lire ce qui est écrit ou à passer directement aux domaines qui vous intéressent.

Les pipelines CI / CD aident à gérer les changements par des cycles de tests automatisés, des environnements de transfert et enfin de la production. Plus vos pipelines de test sont complets, plus vous avez l’assurance que les modifications apportées ne créeront pas d’effets secondaires imprévus dans votre déploiement en production. Cependant, comme chaque modification doit passer par ce processus, il est extrêmement important de garder vos pipelines rapides et fiables pour ne pas inhiber la vitesse de développement.

La tension entre ces deux exigences peut être difficile à équilibrer. Certaines mesures simples peuvent être prises pour améliorer la vitesse, telles que l’extension de votre infrastructure CI / CD et l’optimisation des tests. Cependant, avec le temps, vous serez peut-être obligé de prendre des décisions critiques concernant la valeur relative des différents tests et l’étape ou l’ordre dans lequel ils sont exécutés. Parfois, réduire votre suite de tests en supprimant les tests de faible valeur ou avec des conclusions indéterminées est le moyen le plus intelligent de conserver la vitesse requise par les pipelines très utilisés.

Lorsque vous prenez ces décisions importantes, assurez-vous de comprendre et de documenter les compromis que vous effectuez. Consultez les membres de l’équipe et les parties prenantes pour aligner les hypothèses de l’équipe sur les responsabilités de la suite de tests et sur les domaines prioritaires.

Du point de vue de la sécurité opérationnelle, votre système CI / CD représente l’une des infrastructures les plus critiques à protéger. Étant donné que le système CI / CD a un accès complet à votre base de code et aux informations d’identification à déployer dans différents environnements, il est essentiel de le sécuriser pour protéger les données internes et garantir l’intégrité de votre site ou de votre produit. En raison de sa valeur élevée en tant que cible, il est important d’isoler et de verrouiller votre CI / CD autant que possible.

Les systèmes CI / CD doivent être déployés sur des réseaux internes protégés, non exposés à des tiers. La configuration de VPN ou d’autres technologies de contrôle d’accès au réseau est recommandée pour garantir que seuls les opérateurs authentifiés puissent accéder à votre système. Selon la complexité de la topologie de votre réseau, votre système CI / CD peut avoir besoin d’accéder à plusieurs réseaux pour déployer du code dans différents environnements. S’ils ne sont pas correctement isolés ou isolés, les attaquants qui ont accès à un environnement peuvent utiliser l’island hop_, technique utilisée pour développer l’accès en exploitant des règles de réseau internes plus souples, pour accéder à d’autres environnements en raison de faiblesses dans votre CI / CD. les serveurs.

Les stratégies d’isolation et de sécurité requises dépendent fortement de la topologie de votre réseau, de votre infrastructure et de vos exigences en matière de gestion et de développement. Il est important de garder à l’esprit que vos systèmes CI / CD sont des cibles de grande valeur et qu’ils ont souvent un large accès à vos autres systèmes vitaux. La protection de tous les accès externes aux serveurs et le contrôle strict des types d’accès internes autorisés contribueront à réduire le risque de compromission de votre système CI / CD.

Une partie de ce qui permet à CI / CD d’améliorer vos pratiques de développement et la qualité du code, c’est que les outils aident souvent à appliquer les meilleures pratiques en matière de test et de déploiement. Pour promouvoir le code via vos pipelines CI / CD, chaque modification doit démontrer qu’elle adhère aux normes et procédures codifiées de votre organisation. Les défaillances dans un pipeline CI / CD sont immédiatement visibles et stoppent l’avancement de la version concernée à des étapes ultérieures du cycle. Il s’agit d’un mécanisme de contrôle qui protège les environnements les plus importants du code non fiable.

Cependant, pour bénéficier de ces avantages, vous devez faire preuve de discipline afin de vous assurer que chaque modification de votre environnement de production passe par votre pipeline. Le pipeline CI / CD doit être le seul mécanisme par lequel le code entre dans l’environnement de production. Cela peut se produire automatiquement à la fin des tests réussis avec des pratiques de déploiement continu, ou via une promotion manuelle des modifications testées approuvées et mises à disposition par votre système CI / CD.

Les équipes commencent souvent à utiliser leurs pipelines pour le déploiement, mais commencent à faire des exceptions lorsque des problèmes surviennent et qu’il existe une pression pour les résoudre rapidement. Bien que les temps d’arrêt et autres problèmes doivent être atténués dès que possible, il est important de comprendre que le système CI / CD est un bon outil pour garantir que vos modifications n’introduisent pas d’autres bogues ou ne perturbent pas davantage le système. Le fait de placer votre correctif dans le pipeline (ou simplement d’utiliser le système CI / CD pour annuler) empêchera également le prochain déploiement d’effacer un correctif ad hoc appliqué directement à la production. Le pipeline protège la validité de vos déploiements, qu’il s’agisse d’une version régulière prévue ou d’une solution rapide pour résoudre un problème en cours. Cette utilisation du système CI / CD est une autre raison de travailler pour lier: # Keep-your-Pipelines-Fast [gardez votre pipeline rapidement].

Les pipelines CI / CD encouragent les modifications via une série de suites de tests et d’environnements de déploiement. Les modifications qui répondent aux exigences d’une étape sont soit déployées automatiquement, soit mises en file d’attente pour un déploiement manuel dans des environnements plus restrictifs. Les premières étapes sont censées prouver qu’il vaut la peine de continuer à tester et à rapprocher les changements de la production.

Pour les étapes ultérieures en particulier, reproduire le plus fidèlement possible l’environnement de production dans les environnements de test permet de s’assurer que les tests reflètent avec précision le comportement du changement en production. Des différences significatives entre la mise en scène et la production peuvent permettre de générer des modifications problématiques qui n’ont jamais été détectées comme étant défectueuses lors des tests. Plus il y a de différences entre votre environnement réel et l’environnement de test, moins vos tests mesureront les performances du code lorsqu’il sera publié.

Certaines différences entre la mise en scène et la production sont à prévoir, mais il est essentiel de les gérer et de s’assurer qu’elles sont bien comprises. Certaines organisations utilisent blue-green pour échanger le trafic de production entre deux quasi identiques environnements qui alternent entre être désigné production et mise en scène. Des stratégies moins extrêmes impliquaient de déployer la même configuration et infrastructure de la production à votre environnement de transfert, mais à une échelle réduite. Des éléments tels que les noeuds finaux de réseau peuvent différer d’un environnement à l’autre, mais le paramétrage de ce type de données variables peut vous aider à vous assurer que le code est cohérent et que les différences d’environnement sont bien définies.

L’un des principaux objectifs d’un pipeline CI / CD est de renforcer la confiance dans vos modifications et de minimiser les risques d’impact inattendu. Nous avons discuté de l’importance de maintenir la parité entre les environnements, mais un élément est suffisamment important pour mériter une attention supplémentaire. Si votre logiciel nécessite une étape de création, d’emballage ou de regroupement, cette étape ne doit être exécutée qu’une seule fois et la sortie résultante doit être réutilisée dans l’ensemble du pipeline.

Ce guide aide à prévenir les problèmes qui surviennent lorsque le logiciel est compilé ou empaqueté plusieurs fois, ce qui permet d’injecter de légères incohérences dans les artefacts obtenus. Construire le logiciel séparément à chaque nouvelle étape peut signifier que les tests effectués dans des environnements antérieurs ne visaient pas le même logiciel qui serait déployé plus tard, ce qui invaliderait les résultats.

Pour éviter ce problème, les systèmes CI doivent inclure un processus de construction en tant que première étape du processus de création et de package du logiciel dans un environnement propre. L’artefact résultant doit être versionné et transféré vers un système de stockage d’artefacts pour être extrait des étapes suivantes du pipeline, afin de garantir que la génération ne change pas au fur et à mesure de sa progression dans le système.

Garder rapidement tout votre pipeline est un objectif général ambitieux, mais certaines parties de votre suite de tests seront inévitablement plus rapides que d’autres. Parce que le système CI / CD sert de canal pour toutes les modifications entrant dans votre système, il est important de détecter les défaillances le plus tôt possible afin de minimiser les ressources consacrées aux générations problématiques. Pour ce faire, définissez les priorités et exécutez d’abord vos tests les plus rapides. Sauvegardez des tests longs et complexes jusqu’à ce que vous ayez validé la construction avec des tests plus rapides et plus rapides.

Cette stratégie présente un certain nombre d’avantages qui peuvent vous aider à garder votre processus CI / CD en bonne santé. Il vous encourage à comprendre l’impact des tests sur les performances, vous permet de terminer la plupart de vos tests rapidement et augmente la probabilité d’échecs rapides, ce qui signifie que les modifications problématiques peuvent être annulées ou corrigées avant de bloquer le travail des autres membres.

La hiérarchisation des tests signifie généralement que vous exécutez d’abord les tests unitaires de votre projet, car ceux-ci ont tendance à être rapides, isolés et centrés sur les composants. Ensuite, les tests d’intégration représentent généralement le prochain niveau de complexité et de rapidité, suivis des tests à l’échelle du système et enfin des tests d’acceptation, qui nécessitent souvent un certain niveau d’interaction humaine.

L’un des principes fondamentaux de CI / CD consiste à intégrer les modifications dans le référentiel principal partagé tôt et souvent. Cela permet d’éviter des problèmes d’intégration coûteux lorsque plusieurs développeurs tentent de fusionner des modifications volumineuses, divergentes et conflictuelles dans la branche principale du référentiel en vue de leur publication. En règle générale, les systèmes CI / CD sont configurés pour surveiller et tester les modifications validées dans une ou plusieurs branches.

Pour tirer parti des avantages offerts par CI, il est préférable de limiter le nombre et la portée des branches de votre référentiel. La plupart des implémentations suggèrent que les développeurs s’engagent directement dans la branche principale ou fusionnent les modifications de leurs branches locales au moins une fois par jour.

En règle générale, les branches qui ne font pas l’objet d’un suivi par votre système CI / CD contiennent un code non testé qui devrait être considéré comme une entrave au succès et à la dynamique de votre projet. Minimiser la création de branches pour encourager l’intégration précoce du code de différents développeurs permet d’exploiter les atouts du système et empêche les développeurs de nier les avantages qu’il offre.

En relation avec le point précédent relatif à la détection précoce des échecs, les développeurs doivent être encouragés à exécuter autant de tests localement avant de s’engager dans le référentiel partagé. Cela permet de détecter certains changements problématiques avant qu’ils ne bloquent les autres membres de l’équipe. Il est peu probable que l’environnement de développement local puisse exécuter la suite de tests complète dans un environnement de production, mais cette étape supplémentaire rassure les utilisateurs sur le fait que les modifications apportées répondent aux tests de base et valent la peine d’être intégrées à la base de code plus grande.

Pour que les développeurs puissent effectuer leurs propres tests efficacement, votre suite de tests doit pouvoir être exécutée à l’aide d’une seule commande pouvant être exécutée à partir de n’importe quel environnement. La même commande utilisée par les développeurs sur leurs machines locales devrait être utilisée par le système CI / CD pour lancer les tests sur le code fusionné dans le référentiel. Cela est souvent coordonné en fournissant un script shell ou un fichier makefile pour automatiser l’exécution des outils de test de manière répétable et prévisible.

Pour vous assurer que vos tests se déroulent de la même manière à différentes étapes, il est souvent judicieux d’utiliser des environnements de test propres et éphémères, lorsque cela est possible. Cela signifie généralement que vous devez exécuter des tests dans des conteneurs pour résumer les différences entre les systèmes hôtes et pour fournir une API standard permettant d’associer des composants à différentes échelles. Étant donné que les conteneurs fonctionnent avec un état minimal, les effets secondaires résiduels des tests ne sont pas hérités lors des exécutions ultérieures de la suite de tests, ce qui pourrait altérer les résultats.

Un autre avantage des environnements de test conteneurisés est la portabilité de votre infrastructure de test. Avec les conteneurs, les développeurs ont plus de facilité à répliquer la configuration qui sera utilisée ultérieurement dans le pipeline sans avoir à configurer et à entretenir manuellement l’infrastructure ou à sacrifier la fidélité de l’environnement. Etant donné que les conteneurs peuvent facilement être fusionnés en cas de besoin, puis détruits, les utilisateurs peuvent faire moins de compromis en ce qui concerne la précision de leur environnement de test lors de l’exécution de tests locaux. En général, l’utilisation de conteneurs verrouille certains aspects de l’environnement d’exécution afin de minimiser les différences entre les étapes du pipeline.

Bien que chaque implémentation de CI / CD soit différente, le respect de certains de ces principes de base vous aidera à éviter certains pièges courants et à renforcer vos pratiques de test et de développement. Comme pour la plupart des aspects de l’intégration continue, une combinaison de processus, d’outils et d’habitudes aidera à rendre les modifications de développement plus efficaces et plus efficaces.

Pour en savoir plus sur les pratiques générales de CI / CD et sur la configuration de divers services de CI / CD, consultez d’autres articles avec le CI / Balise CD.