Développer une application n’est jamais simple.
Et plus elle est complexe, plus vous avez de chance de vous retrouver dans l’une des situations suivantes :
- vos équipes de développement prennent de plus en plus de temps pour intégrer les nouveaux morceaux de code ;
- vos testeurs détectent les bugs tardivement ;
- le respect des délais de livraison passe d’un “impératif” à un “on va essayer d’être dans les temps”.
Bref, les problèmes techniques vont vous sauter à la gorge et risquent de faire couler votre projet.
Heureusement, l’ingénierie logicielle et l’approche DevOps ont développée une solution pour chasser ce nuage noir : l’automatisation via un pipeline CI/CD avec Jenkins et Gitlab.
Qu’est-ce qu’un pipeline CI/CD et comment il dope la productivité de vos développeurs ?
Un pipeline CI/CD est une série d’étapes à réaliser durant le développement d’un logiciel.
Son objectif : simplifier le développement logiciel en améliorant la distribution des nouvelles versions d’un logiciel via des tests automatisés.
Il est chargé de surveiller, d’automatiser les tests manuels extrêmement chronophages durant tout le cycle de vie du logiciel. Y compris lors de la phase d’intégration et celle du déploiement.
A chaque étape, le développeur rédige un ou plusieurs scripts qui seront exécutés à des moments précis du processus de livraison.
Dis comme ça, ça peut ressembler à une description d’un théorème obscur sorti tout droit de l’almanach d’un savant fou. Mais c’est en fait un gage de la qualité du code final et de votre capacité à respecter le cahier des charges dans les temps impartis.
Pour comprendre à quel point un pipeline CI/CD va transformer vos processus de création d’applications, il y a 2 concepts essentiels : l’intégration continue (CI) et le déploiement continu (CD).
L’intégration continue CI
Comment faire pour être certain que l’ajout de nouvelles fonctionnalités dans le code-source ne va pas entraîner de problèmes de compatibilité ?
Comment être certain que tous les membres de vos codeurs ont exactement la même version du code que celle de la branche maîtresse ?
Ou que le retrait ou la modification d’un bout de corde ne va pas créer une cascade d’erreurs liées aux dépendances ?
Malheureusement, c’est impossible à garantir.
Surtout si votre code source est composé de milliers de lignes de codes, d’une kyrielles de dépôts et de packages entremêlés (bref, un bon gros plat de spaghetti informatique 🍝).
Par contre, ce que vous pouvez faire, c’est vérifier automatiquement s’il y a une erreur à chaque modification d’un morceau de code.
C’est le principe de l’intégration continue (ou continuous integration, dans la langue de Shakespeare).
Pour citer wikipedia : “L’intégration continue (de l’anglais : Continuous integration, CI), est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l’application développée”.
L’intégration continue permet aux programmeurs de ne plus avoir à tester manuellement si leurs modifications créent des bugs.
L’outil d’intégration analyse constamment les dossiers dans lesquels se trouvent les codes. Et s’il détecte un commit ou un git push dans votre SCM, il lance la compilation de la nouvelle version du code. Ensuite, il lance l’exécution des tests (tests fonctionnels, tests de régression, tests d’intégration, tests d’acceptation, etc.).
A la fin, le programmeur reçoit un rapport de tests lui indiquant s’il y a des erreurs et comment les corriger.
Le déploiement continu (CD)
Réduire le Time-to-Market de vos app pour fournir une valeur client plus rapide vous intéresse ?
Si oui, vous allez adorer la livraison continue (Continuous Delivery) et le déploiement continu (Continuous Deployment).
Concrètement, à chaque commit, la livraison continue va effectuer des tests automatisés et intégrer le code. Ensuite, elle attend une validation humaine pour déployer la dernière version du logiciel dans les différents environnements de tests, d’intégration et de mise en production.
Le déploiement continu va faire exactement pareil. A une différence près : son processus de déploiement automatisé ne nécessite aucune validation humaine.
Et pour pouvoir mettre en place un pipeline mêlant le CI et le CD, vous allez avoir besoin d’outils d’intégration.
Ce qui nous conduit à nos deux champions du jour : GitLab CI/CD et Jenkins.
Qu’est-ce que GitLab CI/CD et Jenkins ?
D’emblée, sachez que vous pouvez utiliser uniquement l’un ou l’autre, ou les deux, en fonction de votre cahier des charges et de votre équipe.
Maintenant, voyons-les en détail.
GitLab
GitLab est un logiciel de gestion de versions (VCS) complet fortement orienté sur la collaboration et le travail en équipe.
Et parmi ses fonctions, GitLab CI/CD.
GitLab CI/CD est un outil de gestion de l’intégration continue et du déploiement continu des projets hébergés sur GitLab.
Parmi ses fonctionnalités, voici quelques-unes qui sont très appréciées par les aficionados du code informatique :
- la gestion du code source ;
- l’intégration d’outils de monitoring et d’analyse ;
- le suivi complet des problèmes ;
- l’usage de la syntaxe YAML ;
- son intégration native avec Git.
Toutefois, contrairement à ce que leurs noms peuvent laisser penser, GitLab et GitHub appartiennent à des entreprises différentes.
GitHub, racheté par Microsoft en 2018, est une autre solution open-source répondant aux mêmes besoins.
Néanmoins, les deux sont basés sur le même logiciel de versions décentralisé et open-source : git.
D’où la ressemblance dans les noms.
Jenkins
Créé en 2004 sous le nom de projet Hudson, Jenkins était d’abord un logiciel interne dédié à l’intégration continue pour l’équipe de développement de Sun Microsystems.
Hudson gagne en popularité grâce à son modèle communautaire, flexible et rapide. Sauf qu’en 2009, Oracle rachète Sun et veut imposer sa vision du processus de développement idéal d’un logiciel.
Plus lent. Plus contrôlé. Bref, moins agile et radicalement différent de la conception des créateurs originaux.
Raison pour laquelle, en 2011, les développeurs originels de Hudson créent un fork du projet sur GitHub. C’est ce fork qui est devenu Jenkins.
Alors qu’est-ce que jenkins et à quoi ça sert ?
Jenkins est un serveur d’intégration continu open-source écrit dans le langage de programmation Java.
Il est 100 % gratuit et mise sur la flexibilité et la rapidité des livraisons.
Autre point fort de Jenkins : son immense bibliothèque qui contient plus de 1900 intégrations à d’autres outils pour passionnés du code informatique.
Voici quelques-uns des plus populaires :
- Amazon Elastic Compute Cloud ;
- GIT ;
- Jira ;
- Maven ;
- Kubernetes ;
- SonarQube Plugin ;
- Docker ;
- Blue Ocean.
Et ce modèle a déjà séduit 11 millions de d’amateurs de programmation.
Comment intégrer un pipeline CI/CD avec Jenkins et Gitlab en 3 étapes ?
Maintenant, entrons dans le vif du sujet : comment intégrer un pipeline CI/CD avec Jenkins et Gitlab.
Avant d’aller plus loin, assurez-vous de cocher ces 2 cases :
- vous avez créer un compte sur Gitlab (si ce n’est pas le cas, voici tuto détaillé sur le sujet) ;
- vous avez déjà créé un projet sur Gitlab.
Prêt ? Commençons.
Etape 1 – Installer Jenkins sur votre serveur
Si vous avez déjà installé Jenkins, vous pouvez sauter cette partie.
1 – Téléchargez et installez Java SE sur votre PC/Serveur
Java SE est une plateforme qui contient les API et bibliothèques de base du langage de programmation Java.
Grâce à ce framework, votre ordinateur sera capable de “comprendre” le langage Java.
Jenkins étant écrit en Java, Java SE est donc indispensable.
Bref, rendez-vous sur la page d’oracle, téléchargez la version correspondante à votre système d’exploitation. Ensuite installez-la comme n’importe quel autre logiciel.
2 – Configurez les variables d’environnement pour Java
Les variables d’environnement sont utilisées pour dire en gros à votre OS :”voici où il faut chercher les fichiers qui contiennent les commandes de Java”.
Ainsi, lorsque vous écrirez des lignes de commande sur votre serveur virtuel Jenkins, l’ordinateur saura où aller chercher.
Rassurez-vous, c’est extrêmement facile :
- Allez dans system -> Paramètre système avancé > Avancé ;
- cliquez sur les variables d’environnement ;
- sélectionnez Java_Home et entre le chemin de navigation suivant : C:\Program Files\Java\jdk-[Numéro de votre version Java] ;
- Dans l’onglet variables système, ajoutez le chemin du fichier Java bin C:\Program Files\Java\jdk-[Numéro de votre version Java]\bin ;
C’est tout.
3 – Téléchargez et configurez Jenkins
Maintenant que votre desktop est configuré pour Java, passons à la prochaine étape : installer Jenkins.
Ca aussi, c’est très simple à faire en quelques clics.
Voici ce que vous avez à faire :
- Téléchargez Jenkins en allant sur l’adresse : https://www.jenkins.io/download/ ;
- lancez l’installation ;
- choisissez “exécuter le service en local ou en tant que “domaine utilisateur”;
Attendez patiemment que l’installation se termine.
Voilà, Jenkins est installé sur votre machine.
Maintenant, il faut le “débloquer”.
Pour cela :
- ouvrez votre navigateur internet et allez sur http://localhost:8080
- Sur l’écran qui s’ouvre, entrez le mot de passe créé par Jenkins dans les fichiers logs (ils sont ici : C:\Program Files\Jenkins\secrets\initialAdminPassword)
- Entrez le mot de passe.
Créez votre tout premier utilisateur – sans oublier de lui donner le rôle d’administrateur – et le tour est joué.
Etape 2 – Créez un nouveau projet Freestyle ou Pipeline sur Jenkins
A cette étape, vous avez déjà un serveur Jenkins qui fonctionne.
Place à la création du pipeline.
Voici la marche à suivre :
- Allez sur Gitlab et copiez l’URL de votre référentiel (le répertoire de travail dans lequel se trouve votre projet) ;
- Connectez-vous sur Jenkins ;
- Allez dans les préférences ;
- Créez un token, ou jeton d’accès, personnel ;
- Stockez votre token dans un fichier texte ;
- Créez un nouvel item et choisissez “Freestyle project”;
- Dans l’onglet “Source Code Project Management”, choisissez Git et collez l’URL de votre projet sur Gitlab ;
- Cochez l’option “Trigger Builds Remotely” et insérez votre token personnel ;
- Rajoutez des étapes dans votre pipeline si nécessaire (celles par défaut font parfaitement l’affaire pour de petits projets) ;
- lancez le build.
Et voilà. A chaque fois que l’équipe de développement modifiera le code stocké sur le compte Git, l’instance Jenkins effectuera toutes les étapes que définies dans votre pipeline.
De plus, vous pouvez aussi modifier votre code directement dans l’interface web de l’IDE de Jenkins.
Vous n’aurez plus qu’à aller dans l’espace “workspace” sur Jenkins pour lancer le build.
Étape 3 : configurez vos pipelines Jenkins
Pour modifier le pipeline créé par défaut, vous allez devoir ouvrir le jenkins file du projet. C’est le fichier de configuration de votre pipeline.
Il se trouve à la racine du projet.
Un jenkinsfile est un simple fichier texte dans lequel vous allez écrire vos instructions dans un langage spécifique à un domaine – ou DSL.
Celui de Jenkins ressemble beaucoup à du code Groovy.
Vous avez le choix entre deux modes d’écriture :
- Le mode déclaratif, plus simple, adapté aux débutants et aux projets de petite envergure. Pour l’utiliser, téléchargez le plugin Pipeline Declarative ;
- Le mode scénarisé, plus complexe et plus puissant, qui s’écrit dans le langage Jenkins Job DSL fourni avec le plugin pipeline.
Après avoir téléchargé le plugin correspondant à vos attentes, installez un environnement de programmation (IDE). Visual Studio Code fera parfaitement l’affaire.
Voici un exemple de fichier Jenkins en mode déclaratif.
// Declarative //
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
// Script //
Et un autre en mode scénarisé.
// Scripted //
node {
stage('Example') {
if (env.BRANCH_NAME == 'master') {
echo 'I only execute on the master branch'
} else {
echo 'I execute elsewhere'
}
}
}
Si vous souhaitez en apprendre plus sur les différentes syntaxes des pipelines groovy, faites un tour sur la documentation officielle.
Ces fichiers sont tous basés sur les concepts propres à Jenkins :
- les étapes ou “steps”, qui sont des tâches uniques chargées d’exécuter un processus spécifique ;
- les phases ou “stages”, qui sont des série d’étapes ;
- les noeuds, aka les machines sur lesquelles Jenkins s’exécute ;
- enfin, les pipelines qui sont des séries de phases.
Place à l’écriture de vos premières directives (voici un billet qui détaille les plus importantes).
Ce serait beaucoup trop long pour cet article, alors faites un tour sur ce billet de blog entièrement consacré à l’écriture des pipelines.
Bonus : Comment créer un pipeline CI/CD uniquement avec GitLab
Vous vous souvenez, plus haut nous vous avons dit que vous pouvez utiliser soit l’un, soit l’autre pour créer votre pipeline CI/CD ?
Eh bien, c’est extrêmement simple : vous n’avez qu’à créer un fichier avec l’extension .gitlab-ci.yml à la racine du référentiel GitLab.
Ensuite, vous définissez les différentes étapes de votre pipeline CI/CD et le tour est joué.
Voici quelques sections les plus courantes dans ces fichiers:
- Stages : définit les différentes étapes du pipeline, chacune ayant un nom significatif.
- +install : dans cette étape, il y a un job appelé install_Dependencies qui s’occupe de l’installation des dépendances du projet en utilisant la commande npm install. C’est une étape courante pour s’assurer que les dépendances sont à jour.
- +Cache :l’étape Node-Modules-Cache utilise une fonction de mise en cache pour stocker le répertoire node_modules/ entre les exécutions de jobs. Il permet d’économiser du temps en évitant de réinstaller les mêmes dépendances à chaque exécution.
- +build : c’est ici qu’à lieu la construction de l’application.
- +security :inclut des tâches liées à la sécurité du code telles que les analyses statiques de sécurité SAST et les analyses dynamiques de sécurité (DAST).
- variables : définit les variables d’environnement qui peuvent être utilisées dans les jobs du pipelineDe
Voilà, maintenant vous savez tout ce qu’il y a à savoir sur les pipelines CI/CD avec Jenkins et GitLab.
Si vous avez besoin de discuter avec un expert, n’hésitez pas à contacter notre chef de projet informatique.
