Intégration continue et déploiement continu

Effectué

Avant de modifier ou de déployer l’infrastructure de votre entreprise, déterminez ce que vous envisagez de créer en explorant les concepts liés à l’intégration continue (CI) et à la livraison continue ou au déploiement continu (CD). Dans cette unité, vous allez découvrir les pipelines CI/CD et voir comment appliquer CI et CD avec GitHub Actions.

CI et CD sont des pratiques opérationnelles qui introduisent une automatisation et un monitoring continus dans toutes les phases de développement, de test et de déploiement de logiciels. Les équipes de développeurs utilisent CI et CD pour gagner en productivité et réduire les problèmes pouvant se produire lors de l’intégration de code nouveau dans une base de code existante.

Intégration continue

Avant le développement des outils CI/CD, l’ensemble du processus (développement, test, déploiement, test) était manuel. Il existait des suites de tests automatisés, mais il fallait les exécuter manuellement ou à des moments planifiées par des équipes d’experts.

L’un des défis les plus importants auxquels les développeurs de logiciels étaient confrontés était le jour de la fusion. Ce jour de la fusion se produisait parce que la plupart des équipes de développement de logiciels travaillaient sur le même code dans différentes branches de contrôle de code source avec un minimum de tests. Le jour de la fusion, toutes les modifications de code étaient réintégrées à la branche primaire. Par conséquent, une journée entière était consacrée à la résolution des problèmes d’intégration au fur et à mesure que les branches des membres de l’équipe étaient fusionnées dans la branche principale et entraient en conflit.

Un principe essentiel de CI consiste à fusionner toutes les nouvelles modifications dans la branche primaire aussi souvent que possible. La fusion continue des modifications permet d’éviter « l’enfer de l’intégration » du jour de la fusion, qui se produisait quand de nombreux développeurs combinaient leurs modifications en même temps.

CI impose aux équipes d’implémenter et d’intégrer fréquemment les moindres modifications du code. L’implémentation de CI signifie que les équipes peuvent constamment tester, compiler, déployer, puis retester le code en production. L’objectif de CI est de détecter et d’éviter les problèmes de production causés par des modifications de code avant qu’ils ne puissent affecter la branche primaire du code ou être déployés chez les clients.

Livraison et déploiement continus

La livraison continue commence là où CI se termine et automatise le processus de livraison à l’environnement d’infrastructure sélectionné. Vous pouvez utiliser la livraison continue pour publier rapidement et durablement les modifications. Après avoir utilisé la livraison continue, vous décidez à l’avance si vous souhaitez déployer les modifications tous les jours, toutes les semaines, tous les mois ou selon un autre planning adapté aux besoins de votre entreprise.

Le déploiement continu va encore plus loin en publiant automatiquement en production les modifications qui réussissent toutes les étapes du pipeline CI/CD. Le déploiement continu est l’un des processus les plus avancés du développement de logiciels et nécessite du code qui teste tous les aspects des fonctionnalités de l’application sans aucune intervention humaine.

Pipelines CI/CD

Un pipeline comprend les processus collectifs qui s’exécutent lorsqu’un événement spécifié se produit. Un grand nombre d’événements font partie du développement de logiciels, et un pipeline CI/CD doit prendre en charge tous les événements associés. Quand un événement déclenche le pipeline, tous les écouteurs de cet événement sont déclenchés et la première étape du processus démarre.

Un pipeline CI/CD s’exécute lorsqu’une nouvelle modification de code le déclenche. Dans la plupart des cas, le processus commence par le clonage ou le téléchargement du code source. Ensuite, l’étape suivante se déclenche, et ainsi de suite.

Chaque fois qu’une modification de code déclenche une exécution CI/CD, toutes les étapes du pipeline s’exécutent. En cas d’erreur dans une étape, le pipeline s’arrête. Les workflows peuvent contenir des sauts logiques qui font que certaines étapes ne s’exécutent pas dans certaines conditions, sans toutefois arrêter l’exécution du pipeline dans son ensemble.

Actions GitHub

GitHub Actions prend en charge tous les événements liés à GitHub et automatise le pipeline CI/CD dans ce module. Dans GitHub Actions, chaque étape définit des actions en JavaScript ou à l’aide d’un conteneur Docker. Les actions sont faciles à créer et composent les étapes d’un pipeline.

Vous pouvez utiliser GitHub Actions pour intégrer parfaitement tout votre code hébergé sur GitHub à un workflow d’automatisation. Le workflow gère plusieurs tâches pour intégrer le code dans plusieurs environnements.

GitHub Actions est un fournisseur populaire pour les pipelines CI/CD en raison de son modèle open source. Les workflows étant open source, ils sont stockés dans des référentiels accessibles à tous les utilisateurs de la plateforme. Les utilisateurs de GitHub peuvent utiliser les actions d’autres utilisateurs ou créer leurs propres actions personnalisées sans installer ou configurer quoi que ce soit d’autre.

La possibilité de partager des actions entre les utilisateurs signifie que vous pouvez utiliser ou personnaliser les actions existantes sans réécrire du code ou des étapes répétés. Dans les unités suivantes, vous utiliserez GitHub Actions dans un conteneur Docker pour définir un pipeline CI/CD qui implémente le déploiement continu d’une application.

Contrôle de vos connaissances

1.

Quelle est la différence entre CI et CD ?

2.

Qu’est-ce qu’un pipeline CI ?