• 10 heures
  • Difficile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 02/10/2024

Découvrez l’intégration continue

Appréhendez 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 ?

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, qui étaient des dépôts centralisés. Ce type de dépôt n’est pas bien adapté aux méthodes de développement moderne, c’est pour cela que les développeurs utilisent des outils décentralisés comme Git.

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. Pour illustrer ces étapes, je vais comparer la CI/CD à une chaîne d’assemblage automobile.

Après une première phase de planification du développement à l’aide de la méthode Scrum, l’intégration continue se réalise en quatre étapes :

  1. Compilez et intégrez votre code.

  2. Testez votre code.

  3. Mesurez la qualité de votre code.

  4. Gérez les livrables de votre application.

Toutes les étapes se feront sur GitLab et seront lancées automatiquement grâce à GitLab CI.

Les étapes de l'intégration continue sont build, test, quality, package.
Étapes de l’intégration continue sur GitLab CI

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.

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 définir la priorité des tâches dans le 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 les différents membres de l’équipe.

Lors de la planification des développements, il est aussi nécessaire d’intégrer le plus tôt possible les contraintes de sécurité. Dans un projet, la question de la sécurité intervient souvent à la fin de celui-ci. Or, plus la sécurité est pensée tard dans le projet, plus elle coûte cher car elle peut fortement impacter ce dernier, voire remettre en cause un projet pour une non-conformité avec la législation.

Depuis plusieurs années, et avec le mouvementDevSecOps, les équipes utilisent le Shift Left. Celui-ci consiste à penser la sécurité dès la planification du développement. 

Le coût de la sécurité augmente fortement en fonction du moment de sa mise en place dans le cycle de développement.
Coût de la sécurité selon les étapes du développement

Durant la planification des développements, une approche collaborative consiste à définir les exigences et les tests en utilisant des exemples réels et des documents déjà à disposition au lieu de données abstraites. C’est ce qu’on appelle la spécification par l’exemple.

🚗 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ée à définir les tâches à faire durant la journée.

Nous verrons plus en détail cette première étape dans le chapitre 3 de cette partie.

Compilez et testez votre code

Versionnez votre code source

Lors du développement d’une application, le développeur code sur son poste de travail. Il doit rendre disponible le code sur lequel il a travaillé à tous les autres développeurs. 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 récente et ne faire l’objet d’aucune dépendance externe.

Orchestrez les étapes de votre intégration continue

Toutes les étapes de la chaîne d’intégration continue 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.

Compilez votre code

La première étape de la CI/CD (celle qui paraît la plus évidente) est la compilation du 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 de ne plus se soucier de modifications de code qui casseraient la compilation.

Le développeur doit 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, prenant en compte toutes les modifications dans son code source. Si la compilation est en erreur, le code est alors rejeté et le développeur doit corriger ses erreurs.

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

Nous verrons cette étape dans le chapitre 4 de cette partie.

Testez votre code

Dans la deuxième é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.

La multiplicité des tests unitaires oblige à les maintenir dans le temps, au fur et à mesure des évolutions du code.

🚗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 cette étape de test dans le chapitre 4 de cette partie du cours, à la suite de la compilation.

Garantissez la qualité de votre code et packagez votre application

Garantissez 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.

Testez la sécurité de votre code

Dans l’approche DevSecOps, un autre type de tests joue un rôle important lors de la phase d’intégration continue : les tests de sécurité. La sécurité est devenue de plus en plus importante dans la création d’applications. Il est donc nécessaire de se prémunir d’attaques qui pourraient compromettre l’application en cours de développement. Ces tests de sécurité permettent de détecter au plus tôt les failles de sécurité dans les applications.

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.

🚗 La qualité du 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 5 de cette partie du cours.

Packagez votre application

Le code, une fois compilé, doit être déployé dans un dépôt de livrables et versionné. Les binaires qui sont produits sont appelés artéfacts. Ces artéfacts 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 artéfacts sont disponibles dans un stockage, centralisé et organisé, de données. Ce peut être une ou plusieurs bases de données où les artéfacts 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 également abordée au chapitre 5 de cette partie 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 l’outil GitLab. Celui-ci 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 des 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 ce cours.

Vous n’avez pas besoin de connaître Spring Boot ni d’être expert en développement Java. Le code vous sera fourni et vous lui ferez passer toutes les étapes du pipeline CI/CD.

En résumé

  • L’intégration continue consiste à générer et tester automatiquement du code à chaque modification du code source d’une application.

  • La planification du développement se fait avec la méthode Scrum.

  • L’intégration continue se déroule en quatre étapes : 

    • la compilation et l’intégration du code pour produire les artéfacts de livraison ;

    • le lancement automatique des tests unitaires pour vérifier que le code fonctionne comme prévu ;

    • la mesure de la qualité du code produit, pour vérifier qu’il sera facilement maintenable sur la durée ;

    • la gestion des livrables pour obtenir les artéfacts prêts à être déployés en production ou sur l’environnement de test. 

  • GitLab permet la mise en place de toutes les étapes de l’intégration continue.

Vous avez maintenant une vue d’ensemble des différentes étapes qui composent l’intégration continue. Dans le chapitre suivant, nous allons entrer dans le détail de la planification.

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