• 10 heures
  • Difficile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 22/02/2021

Qu'est-ce que l'intégration continue ?

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Tirez le maximum de ce cours

Bienvenue à tous ! Dans ce cours, nous allons mettre en place l'intégration continue et la livraison continue sur un projet de développement.

Comment est composé ce cours ?

Dans l'ensemble du cours, je vous propose de travailler sur un projet exemple de Spring : le projet PetClinic. PetClinic est un projet de développement en Java open source, utilisé pour des exemples comme celui-ci. C'est une plateforme de gestion de clinique vétérinaire en ligne. Nous allons mettre en place de l'intégration continue et la livraison continue sur cette application, dans sa version microservice. Ça nous permettra de mettre en pratique tout au long du cours !

Ce cours sera divisé en deux parties ; chacune de ces parties abordera un pan de ce cycle CI/CD.

Cycle d'intégration et de livraison continue avec la démarche DevOps
Cycle d'intégration et de livraison continues avec la démarche DevOps

Dans la première partie, nous mettrons en place l'intégration continue en suivant chacune de ses étapes, de la planification aux tests, en passant par l'intégration.

Dans la deuxième partie, nous poursuivrons la mise en place de la méthode avec la livraison continue, de la conteneurisation à la supervision de l'application.

Dans ce cours, vous utiliserez Gitlab pour mettre en place votre pipeline
Dans ce cours, nous utiliserons GitLab CI

Tout au long de ce cours, nous utiliserons GitLab CI, un outil très performant et permettant de mettre en place chacune des étapes du cycle avec un seul et même outil. Néanmoins, je vous présenterai à chaque étape les autres outils que vous pouvez utiliser.

Comment utiliser ce cours ?

Ce cours est très complet, il regroupe énormément de pratiques et vous fera voir de nombreux outils et notions. Vous n'êtes pas obligé de le suivre du début à la fin ! Selon votre besoin, vous serez peut-être intéressé par l'intégration continue uniquement, ou la livraison continue uniquement, peut-être même seulement par une étape du cycle. En ce cas, ne suivez que le chapitre en question ! Il est possible de n'effectuer que certaines étapes du cycle CI/CD. 😊

Qu'est-ce que l'intégration continue ?

Dans ce chapitre, nous allons introduire et expliquer ce qu'est l'intégration continue, et quelles sont les différentes étapes à mettre en œuvre lors de la mise en place de celle-ci.

Mais qu'est ce que l'intégration continue ? En quoi diffère-t-elle de la livraison continue ?

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel, consistant à vérifier, à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée.

Dans une entreprise, il est courant qu'il y ait plusieurs développeurs travaillant sur la même application, et même sur le même code. Avant l'apparition de Git, comme contrôle de code source distribué, il existait d'autres outils comme SVN ou CVS, mais le dépôt était centralisé, ce qui menait à de nombreux problèmes d'intégration du code.

Le principe de l'intégration continue est justement de détecter ces problèmes d'intégration au plus tôt dans le cycle de développement.

🏭🚗 Afin de détecter ces problèmes, il est nécessaire de passer par plusieurs étapes que nous allons détailler au fur et à mesure, et afin d'illustrer ces étapes, je vais comparer la CI/CD à une chaîne d'assemblage automobile

Toutes les étapes se feront sur GitLab. Les étapes 2 à 4 seront lancées automatiquement grâce à GitLab CI :

Etapes de l'intégration continue sur Gitlab
Étapes de l'intégration continue sur GitLab

Dans la suite de ce chapitre, nous allons voir chacune des étapes de l'intégration continue, ainsi que, pour chaque étape, les outils que vous pouvez utiliser pour la mettre en place.

Étape 1 : Planifiez votre développement

Afin de savoir quoi développer, il est nécessaire d'avoir à disposition un outil permettant la collaboration entre les développeurs. Cet outil permettra notamment de gérer les différentes releases et toutes les fonctionnalités, de garantir la priorité du backlog, etc.

Intervenant tout au long du projet, la collaboration de toute l'équipe est nécessaire pour assurer la planification du projet. Cette planification est étroitement liée à la méthodologie Scrum. Elle a pour but de découper le projet en petites tâches à réaliser par toute l'équipe.

Sur notre chaîne d'assemblage, la planification représente la répartition des tâches de chaque collaborateur, ou encore le brief du matin destiné à définir les tâches à faire durant la journée.

Nous verrons cette première étape dans le chapitre 2 de cette partie.

Étape 2 : Compilez et intégrez votre code

Le contrôle de code source

Le code source se doit d'être disponible à chaque instant sur un dépôt central. Chaque développement doit faire l'objet d'un suivi de révision. Le code doit être compilable à partir d'une récupération fraîche, et ne faire l'objet d'aucune dépendance externe. Même s'il existe des notions de branche, la création d'une branche doit être évitée le plus possible, privilégiant le développement sur la branche principale ; cela évite de maintenir plusieurs versions en parallèle. Ce genre de pratique est appelé trunk-based development.

L'orchestrateur

Ensuite, toutes les étapes doivent être automatisées par un orchestrateur, qui saura reproduire ces étapes et gérer les dépendances entre elles. De plus, l'utilisation d'un orchestrateur permet de donner accès à tous, et à tout moment, à un tableau de bord qui donnera l'état de santé des étapes d'intégration continue. Ainsi, les développeurs ont au plus tôt la boucle de feedback nécessaire, afin de garantir que l'application soit prête à tout moment. De plus, l'orchestrateur permettra d'aller plus loin dans la livraison continue, comme on le verra dans la suite du cours.

🏭🚗L'orchestrateur est le tapis roulant de notre chaîne d'assemblage, qui va guider toutes les pièces de la voiture petit à petit, afin d'arriver au résultat final.

La première étape, et celle qui paraît la plus évidente, est de compiler le code de manière continue. En effet, sans cette étape, le code est compilé manuellement sur le poste du développeur, afin que ce dernier s'assure que son code compile.

🏭🚗Si nous comparons cette étape à notre chaîne d'assemblage automobile, c'est ici que l'on assemble toutes les pièces de la voiture.

La mise en place d'une première étape de compilation dans un processus d'intégration continue permet justement de ne plus se soucier si des modifications de code cassent la compilation. Le développeur doit alors s'assurer de bien envoyer son code source sur le dépôt central. En faisant cela, il déclenche une première étape de compilation, avec toutes les modifications des autres développeurs. Si la compilation ne se fait pas, le code est alors rejeté, et le développeur doit corriger ses erreurs.

Après cette première étape, le code devient plus sûr, et le dépôt de code source garantit qu'à chaque instant, un développeur récupère un code qui compile. Dans cette étape, les tests ne sont pas encore exécutés. Le code peut donc être de mauvaise qualité.

Nous verrons cette étape dans le chapitre 3 de ce cours.

Étape 3 : Testez votre code

Les tests unitaires

Dans cette étape, l'orchestrateur se charge de lancer les tests unitaires à la suite de la compilation. Ces tests unitaires, généralement avec un framework associé, garantissent que le code respecte un certain niveau de qualité.

Plus il y a de tests unitaires, plus le code est garanti sûr. Évidemment, l'orchestrateur ne peut lancer que les tests qui ont été codés par les développeurs, et ne peut pas inventer de nouveaux cas de tests.

Ces tests doivent s'exécuter de la manière la plus rapide possible, afin d'avoir un feedback le plus rapide lui aussi. Pour arriver à ce niveau, il est nécessaire que les tests unitaires n'aient aucune dépendance vis-à-vis de systèmes externes, comme par exemple une base de données, ou même le système de fichiers de la machine.

Les tests unitaires apportent 3 atouts à la production :

  • trouver les erreurs plus facilement. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin ;

  • sécuriser la maintenance. Lors d'une modification d'un programme, les tests unitaires signalent les éventuelles régressions. En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code ;

  • documenter le code. Les tests unitaires peuvent servir de complément à la documentation ; il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests, eux, correspondent à la réalité de l'application.

L'ensemble des tests unitaires doivent être relancés après une modification du code, afin de vérifier qu'il n'y ait pas de régressions (l'apparition de nouveaux dysfonctionnements). 

La multiplicité des test unitaires oblige à les maintenir dans le temps, au fur et à mesure que le développement avance.

🏭🚗Toujours sur notre chaîne d'assemblage, les tests constituent l'assurance qualité de la voiture, à chaque étape d'assemblage de celle-ci.

Nous verrons l'étape 3 dans le chapitre 3 de ce cours, à la suite de la compilation.

Étape 4 : Mesurez la qualité de votre code

Maintenant que les tests unitaires sont écrits et exécutés, nous commençons à avoir une meilleure qualité de code, et à être rassurés sur la fiabilité et la robustesse de l'application. Grâce à la compilation et aux tests unitaires, nous pouvons maintenant mesurer la qualité du code. Tout ceci permet aux développeurs de maintenir dans le temps un code de très bonne qualité, alertant l'équipe en cas de dérive des bonnes pratiques de tests.

Lors de l'étape de qualité de code, nous cherchons à assurer la plus petite dette technique possible de notre application. La dette technique est le temps nécessaire à la correction de bugs ou à l'ajout de nouvelles fonctionnalités, lorsque nous ne respectons pas les règles de coding. La dette est exprimée en heures de correction. Plus cette dette est élevée, plus le code sera difficile à maintenir et à faire évoluer.

L'étape de qualité de code mesure aussi d'autres métriques, comme le nombre de vulnérabilités au sein du code, la couverture de test, mais aussi les code smells (qui sont des mauvaises pratiques à ne pas implémenter), la complexité cyclomatique (complexité du code applicatif) ou la duplication de code. C'est le rôle du développeur de respecter les normes définies et de corriger au fur et à mesure son code.

Afin de renforcer la qualité du code et de ne pas autoriser le déploiement d'un code de mauvaise qualité, nous pouvons implémenter un arrêt complet du pipeline d'intégration continue, si le code n'atteint pas la qualité requise.

🏭🚗La qualité de code constitue le banc d'essai de notre chaîne d'assemblage, où l'on teste différents paramètres comme la qualité du freinage, le moteur, la résistance aux chocs, etc.

Cette étape sera vue dans le chapitre 4 du cours.

Étape 5 : Gérez les livrables de votre application

Le code, une fois compilé, doit être déployé dans un dépôt de livrables, et versionné. Les binaires produits sont appelés artefacts. Ces artefacts doivent être accessibles à toutes les parties prenantes de l'application, afin de pouvoir les déployer et lancer les tests autres qu'unitaires (test de performance, test de bout en bout, etc.). Ces artefacts sont disponibles dans un stockage, centralisé et organisé, de données. Ce peut être une ou plusieurs bases de données où les artefacts sont localisés en vue de leur distribution sur le réseau, ou bien un endroit directement accessible aux utilisateurs.

🏭🚗Sur notre chaîne d'assemblage, la gestion des livrables est l'entrepôt des voitures finies. Il est tout à fait possible de prendre une de ces voitures afin de lancer des tests complémentaires, ou alors de la vendre, ce qui correspondrait à la mise en production.

La gestion des livrables sera aussi abordée au chapitre 4 du cours, à la suite de la qualité du code.

Utilisez GitLab pour mettre en place un pipeline CI/CD

Dans la suite de ce cours, nous ferons le choix de GitLab. Cet outil a l'avantage d'avoir toutes les briques nécessaires à la mise en place de l'intégration continue, sans rentrer dans des étapes complexes de mise en place des outils, ainsi que les connexions associées.

Afin de pouvoir illustrer l'intégration continue, nous allons travailler sur un projet open source : la mise en place du site web d'une clinique vétérinaire via Spring Boot. Toutes les étapes de mise en place de l'intégration continue seront entièrement détaillées dans la suite de cette partie.

En résumé

Ça y est, ce premier chapitre de présentation de l'intégration continue est terminé !

Pour résumer, voici les grandes étapes de l'intégration continue :

  1. La planification du développement avec la méthode Scrum.

  2. La compilation et l'intégration du code grâce à Maven et Git.

  3. Le lancement automatique des tests unitaires, pour vérifier que le code fonctionne comme prévu.

  4. La mesure de la qualité du code produit, pour vérifier qu'il sera facilement maintenable sur la durée.

  5. La gestion des livrables pour obtenir les artefacts prêts à être déployés en production ou sur l'environnement de test. 

Vous avez maintenant une meilleure vue d'ensemble des différentes étapes qui la composent. Il est possible de mettre toutes ces étapes en place grâce à GitLab, et notamment son moteur GitLab CI. C'est ce que vous allez faire dans la suite de cette partie !

Exemple de certificat de réussite
Exemple de certificat de réussite