Si vous faites des projets informatiques ou que vous êtes simplement passionné, vous avez probablement déjà rencontré la notion « d’intégration continue » ou de « continuous integration ». Process souvent utilisé lors du développement de nos projets, on vous propose un tour d’horizon du sujet avec un de nos experts GitLabGitLab, c’est une plateforme permettant d’héberger et de gérer des projets web de A à Z..
L’intégration continue (ou continuous integration) a pour but de mettre en place un processus de publication automatisé et simplifié, qui permet une livraison plus rapide d’un logiciel aux utilisateurs finaux.
En d’autres termes, l’intégration continue permet d’automatiser un certain nombre de tâches récurrentes (compilation, tests unitaires, tests d’intégration) et si on va un peu plus loin, de faire du déploiement sur les environnements de tests et de production.
Dans la pratique, l’intégration continue c’est ni plus ni moins qu’un pipeline, composé de différentes étapes. Voilà un pipeline classique (qu’on retrouve dans beaucoup de nos projets) :
Utiliser un outil d’intégration continue, c’est aujourd’hui un confort indispensable :
Gitlab, Jenkins, Ansible, AzureAzure est la plateforme de Cloud de Microsoft. Devops… il existe plusieurs solutions d’intégration continue qui sont relativement similaires, même si de notre côté, on a une grosse préférence pour Gitlab ! Pour découvrir dans le détails ces solutions, c’est par ici : les outils d’intégration continue.
Il y a toujours un avant ! Avant l’intégration continue, c’était comment ? Dans un premier temps, l’application était testée et compilée sur notre poste. Ensuite, on copiait/collait la partie binaire de l’application (fichier war, jar, etc.) sur le serveur de production. À ce moment là, on croisait les doigts pour que ça marche… Pas idéale comme solution !
L’intégration continue a été créée pour pallier les problèmes des process précédents. Avant, les environnements n’étaient pas symétriques, il y avait de grandes différences entre ce qu’on avait sur le poste de développement et ce qu’on avait sur l’environnement de production.
La professionnalisation du monde IT a aussi porté cette évolution ! Aujourd’hui, c’est fini l’économie des environnements… Lorsqu’on développe un projet, on passe par plein d’environnements différents qui permettent de valider le code, le tester, vérifier si cela marchera bien avec les environnements de production, etc. La multiplication des environnements a largement complexifié la compilation des projets.
L’objectif étant d’automatiser le processus de manière industrielle afin d’augmenter la qualité des livrables.
Il y a toujours au minimum 3 environnements dans les projets de développement : l’environnement de développement, l’environnement de test, l’environnement de production.
Sur les projets clients conséquents, il y a même plusieurs environnements de développement, plusieurs environnements de tests, des environnements de pré-production, puis un environnement de production. On peut facilement se retrouver avec 8 environnements à gérer.
L’intégration continue, c’est devenu un incontournable du monde du développement. Globalement, une solution d’intégration continue peut être mise en place sur tous les projets alors on vous conseille de le faire pour tous vos nouveaux projets !
Pourquoi et comment écrire des tests unitaires ? Définition et implémentation dans une application Java Springboot
Si vous faites des projets informatiques ou que vous êtes simplement passionné, vous avez probablement déjà rencontré la notion « d'intégration continue » ou de « continuous integration ». Process souvent utilisé lors du développement de nos projets, on v
Nous traiterons dans cet article des questions à aborder lors de l’élaboration d’une stratégie d’implémentation BI. Nous n’aborderons par contre pas les problématiques de modélisation ou de qualité de données, qui sont d’autres sujets.