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

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 🙂

Si votre code est en JS (Angular, React, etc.), les phases de compilation ne vous concernent pas. Vous pouvez passer directement à la rédaction des scripts.

Compilation (ne concerne pas les projets JS)

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 Graden ou Mavle qui permette de compiler l’application.

Compiler son code : les instanciations de serveurs (ne concerne pas les projets JS)

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 : Docker). 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 Docker 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 au final, c’est simplement 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 !

Intégration continue : maîtriser le pipeline

L’intégration continue dans la pratique, c’est ni plus ni moins qu’un gros pipeline composé de différentes étapes à valider. Voilà un pipeline classique qu’on retrouve dans beaucoup 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

À 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).

Intégration continue : notre retour d’expérience

Indispensable dans tous les projets

Chez AXOPEN, on utilise l’intégration continue dans tous nos projets et c’est juste génial ! Honnêtement, le plus dur ça 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, continuité des produits de qualité qui sont livrés aux clients fréquemment et de façon prévisible. On réduit les difficultés en augmentant la fréquence de vos livraisons de produits.

On vous conseille son utilisation sans modération 🙂

Outils d’intégration continue : davantage 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 ton 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 producation 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 !