Nous contacter

Votre message a bien été envoyé !

Mince, visiblement quelque chose est cassé de notre côté. Que diriez vous de nous envoyer un email directement sur contact@plunge.cloud ?

Retour vers les articles

À quoi ressemble une chaîne d’intégration continue ?

Martin Catty
Martin Catty
Publié le 9 janvier 2020 08:00:00 CET

Pour comprendre ce qu'est une chaîne d'intégration continue en devops, vous pouvez visualiser une chaîne d'assemblage permettant de fabriquer une voiture par exemple.

Sur cette chaîne, différents intervenants vont réaliser des opérations sur le produit. Ces opérations, mises bout à bout, formeront le produit final. Ces étapes sont la plupart du temps chronologiques, et se déroulent en séquence. Difficile en effet de peindre la voiture, si l'on n'a pas mis les portes.

Dans le domaine du logiciel, les choses sont assez identiques : à chaque fois que nous allons introduire des modifications dans notre application, nous allons en reconstruire une version finale, assemblée, en rejouant les différentes étapes.

Perdu(e) dans le "jargon" du devops ? Téléchargez notre glossaire et obtenez une définition simple des termes  techniques liés au devops.

Les étapes d'une chaîne d'intégration continue

D'abord, il n'y a pas de modèle type pour une chaîne d'intégration. Libre à chacun d'usiner son produit comme il le souhaite, et une chaîne d'intégration se raffine en permanence.

À l'instar d'une chaîne d'assemblage, certaines étapes peuvent être améliorées au fil du temps : pour être réalisées plus rapidement, consommer moins d'énergie, etc.

Certaines étapes peuvent également être optionnelles, actionnables manuellement, ou peuvent même être autorisées à échouer car jugées non critiques.

Dans les projets sur lesquels nous travaillons, nous retrouvons généralement ces différentes étapes :

  1. Packaging d'une image de base
  2. Packaging de l'image correspondant au code modifié
  3. Tests unitaires et tests d'intégration
  4. Analyse de la qualité du code source
  5. Construction de la ou les images de production
  6. Analyse de la sécurité des images
  7. Génération de la documentation
  8. Déploiement de la ou les images vers un environnement donné

Les différentes étapes d'une chaîne d'intégration continue

1. Packaging de l'image de base

À l'inverse de la production physique d'un objet, le numérique nous offre un avantage immense : celui de pouvoir dupliquer un objet virtuel en un instant. Copier du code est extrêmement simple et peu coûteux.

Le principe de la construction de l'image de base est donc de construire une image de référence de l'application, qui ne va pas contenir de code mais uniquement les dépendances de celle-ci.

Étant donné que les dépendances ne changent pas aussi fréquemment que le code, on peut faire en sorte de repartir de cette image pour construire notre image applicative.

Concrètement, si mon application a deux dépendances, A et B, elles seront installées dans cette étape de construction de l'image de base. Si aucune dépendance n'a changé, alors on ne ré-installe rien.

Cela permet d'éviter de repartir de 0 quand on crée l'image applicative et donc de ré-installer systématiquement des dépendances, que ça soit via composer, bundler, npm ou autre.

2. Packaging de l'image applicative

Cette étape est très simple : en repartant de l'image de base, on crée notre image applicative en lui ajoutant le code. C'est à dire qu'on dispose du code le plus à jour possible qui vient d'être envoyé par le développeur.

3. Tests unitaires et tests d'intégration

Dès lors que le packaging de l'image applicative est réalisé, on peut jouer les tests. Il peut s'agir de tests unitaires, d'intégration ou toute autre forme de tests.

Cette étape est par essence bloquante. Notre chaîne d'intégration continue est garante de la non régression, on ne veut donc pas aller plus loin si un problème a été introduit.

4. Analyse de la qualité du code source

Plus les équipes techniques progressent, plus elles raffinent leurs standards. Généralement, elles adoptent des conventions sur la lisibilité que doit avoir le code, mais également le niveau de complexité autorisé dans celui-ci.

Par exemple, on peut vouloir interdire qu'une méthode fasse plus de 20 lignes de code, pour maintenir un bon niveau de lisibilité et de découplage, s'assurer que l'on n'a pas d'espaces inutiles, ou encore faire appel à toute autre règle que l'équipe souhaite mettre en place.

Selon les équipes, cette étape peut être bloquante ou non. Il est difficile d'avoir des bases de code qui respectent 100% des standards en place. Généralement, on veille donc à minima à ne pas dégrader la situation existante.

5. Construction des images de production

On parle ici volontairement des images, car une même codebase peut donner lieu à la génération de plusieurs images. On peut par exemple avoir une image qui corresponde à l'application en elle-même, et une image dont le but est de servir les contenus statiques (assets de type images, javascript, css).

Si on ne ré-utilise pas exactement l'image construite pour jouer les tests, c'est principalement parce que les dépendances peuvent être légèrement différentes. L'environnement de tests contiendra par exemple une dépendance permettant de connaître la couverture des tests, inutile en production.

Et pour la production, on souhaite avoir l'image la plus légère possible, ne serait-ce que pour en réduire la surface d'attaque.

6. Analyse de la sécurité des images

Ces images une fois produites, on veut vérifier que l'on n'a pas introduit de failles de sécurité. Pour cela, deux types de vérifications possibles : SAST (Static Application Security Testing) et DAST (Dynamic Application Security Testing).

La première nous permettra de vérifier si les dépendances de notre application ne contiennent pas des failles de sécurité connues, par exemple une version d'un paquet installé qui sera vulnérable. Le SAST scanne donc les vulnérabilités sur base du code source de l'application.

Le DAST vise lui à vérifier la sécurité d'une application en cours d'usage : on va la déployer dans un environnement donné et vérifier un certain nombre de choses à l'usage, par exemple qu'elle n'est pas sujette à des failles XSS. Le DAST ne nécessite pas d'accès au code, il teste la robustesse de l'application de la même façon que pourrait le faire un utilisateur malveillant.

7. Génération de la documentation

Cette étape est généralement conditionnée à ce que la version du code envoyée soit finalisée, c'est à dire généralement quand on prépare une « release ».

Par exemple, si l'on développe une API, on peut vouloir générer la documentation associée sur base des annotations du code, et la mettre à disposition des utilisateurs de cette API.

Cela peut aussi concerner la génération d'une documentation à usage interne des équipes de développement.

8. Déploiement de la ou les images vers un environnement donné

Il est assez rare d'avoir des pipelines où cette étape est automatisée. Généralement, on préférera pouvoir la déclencher manuellement, à la demande. Selon les environnements vers lesquels on veut pouvoir déployer, les droits nécessaires seront également différents.


Vous savez maintenant tout de l'anatomie d'un pipeline d'intégration continue. Mais encore une fois, c'est à vous de déterminer quelles en seront les étapes clés.

Évidemment, il ne faut pas mettre la barre trop haut dans un premier temps, et plutôt procéder une étape à la fois : c'est de cette manière que l'on s'engage dans une démarche d'amélioration continue.

Télécharger notre Glossaire du Devops

Partager l'article sur

Laisser un commentaire