Mettre en place l’intégration continue : retour d’expériences !

mettre en place l'intégration continue

Vous démarrez un projet d’application et voulez mettre en place un outil d’intégration continue pour votre projet ? On vous partage nos conseils et notre retour d’expérience sur le sujet !

Les pré-requis pour la mise en place de l’intégration continue

Quel que soit l’outil d’intégration continue choisi (Gitlab, Jenkins, ….), les pré-requis sont identiques 🙂

La compilation

Pour pouvoir mettre en place l’intégration continue sur un projet, il faut pouvoir compiler son code en lignes de commandes (parce que tout se fait par des scripts).

Par exemple, avant pour une application Java, on générait le war depuis l’IDE Eclipse. Pour faire de l’intégration continue, ce n’est pas possible. Il faut utiliser un outil comme Gradle ou Mavle qui permette de compiler l’application.

Compiler son code : les instanciations de serveurs

Pour compiler son code sur n’importe quel serveur, on utilise souvent ce qu’on appelle les instanciations de serveurs. Les instanciations sont faites pour compiler puis, sont jetées une fois le travail terminé (exemple : Dockers). La manipulation est la suivante :

  • Lancer un environnement sur lequel on récupère le code source
  • Lancer un gestionnaire de paquets ou équivalent pour récupérer les librairies et les dépendances
  • Compiler sur la machine et récupérer le binaire de la compilation.
  • Remonter le binaire sur la plateforme d’intégration continue
  • Jeter la VM ou le Dockers qui vous a permis de compiler.

Vous avez maintenant un binaire qui peut passer simplement d’environnement en environnement !

La rédaction des scripts

Pour toute intégration continue, il y a une phase de rédaction de scripts qui permettra d’automatiser les actions selon nos besoins. Dans la pratique, on rédige un mini script qui fera automatiquement tout ce qu’on faisait manuellement, à partir des sources du projet.

La rédaction des scripts est plutôt simple quand vous savez ce que vous voulez, et cela doit être fait dès le début du projet.

Il faut garder à l’esprit que l’intégration continue, c’est simplement au final des lignes de commandes exécutées, dans un ordre précis, à des étapes précises du workflow du projet. Tout ce qui peut être fait en ligne de commandes, vous pouvez l’intégrer au process d’intégration continue.

Vous avez maintenant tout ce qu’il vous faut pour mettre en place l’intégration continue 🙂 Attention tout de même lors de la première mise en place, il est nécessaire de vérifier que tout a été déployé comme il faut et tester la fiabilité du process mis en place. Ensuite, plus le temps passe, plus le système peut être considéré comme robuste !

Mise en place de l’intégration continue : maitriser le pipeline

Dans la pratique, l’intégration continue c’est un beau pipeline composé de différentes étapes à valider. Pour exemple, voici le pipeline que nous retrouvons dans l’essentiel de nos projets :

  • 1 – Phase de build : compilation de l’application pour un environnement.
  • 2 – Phase de tests : tests effectués de manière unitaire. Généralement, un test se résume à une ligne de commande. On laisse ensuite faire la librairie qui exécute tous les tests.
  • 3 – 1ère livraison sur un environnement de test
  • 4 – Réalisation d’une batterie de tests qui viennent valider la livraison par rapport à votre cahier d’exigences.
  • 5 – Phase de livraison finale : livraison du projet sur un environnement de production.

A notre sens, le plus gros intérêt du pipeline est qu’on peut passer, en plus de scripts de base, d’autres types de scripts, comme par exemple les scripts de migration de base de données .

Parce que oui, quand vous voulez mettre à jour votre projet, il y a l’application que vous souhaitez mettre à jour, mais il y a souvent aussi d’autres briques applicatives qu’il va falloir mettre à jour en fonction de la livraison ( par exemple : la base de données).

Retour d’expériences

L’intégration continue est indispensable dans tous les projets

Chez AXOPEN, on utilise l’intégration continue dans tous nos projets et c’est juste GENIAL ! Honnêtement, le plus dur reste la prise en main et la première configuration de l’outil d’intégration continue. Ensuite, si vous avez d’autres projets à faire dans une stack similaire, la configuration peut être semblable, et ça va d’autant plus vite !

Le plus c’est que le système s’inscrit parfaitement dans la méthode agile ! Les projets sont livrés aux clients fréquemment et de façon prévisible, on assure la continuité ! De plus, on réduit les difficultés en augmentant la fréquence des livraisons de produits.

On vous conseille son utilisation sans modération 🙂

Outils d’intégration continue : c’est d’avantage de possibilités

Au-delà de tout ce qu’on a cité ci-dessus, des outils d’intégration continue comme Gitlab permettent de faire bien plus que seulement builder, tester et déployer ! Seule votre imagination est la limite 😉 On peut par exemple faire automatiquement :

  • Attribution de labels « en recette », « en prod » sur les issues
  • Envoi de messages sur des messageries instantanées (comme Mattermost) lors d’une livraison avec la liste des changements
  • Création d’une milestone lors de la livraison en production avec toutes les issues comprises dans la livraison pour archiver/documenter
  • Fermeture automatique d’issues selon certains critères (vieilles demande de contact, issue abandonnées, etc.)
  • Mise à jour du SQL en plus des sources de l’application

Enfin, si il y a une chose que vous devez garder à l’esprit, c’est que l’intégration continue, ça peut se résumer simplement à des lignes de commandes, exécutées dans un ordre précis, à des étapes précises du workflow du projet. En bref, tout ce que vous pouvez faire en lignes de commandes, vous pouvez l’intégrer au process d’intégration continue !

Camille Regnault