INTRODUCTION À L’INTÉGRATION CONTINUE

Approche naïve de production du logiciel :

• Le développement doit être incrémental pour gérer les incertitudes :
• Le développement doit être industrialisé pour gérer la complexité.
Une usine logicielle est une chaîne de fabrication du logiciel, depuis les sources jusqu'au livrable.
Elle permet d’automatiser toutes les tâches qui peuvent l’être dans le cadre du processus de la
production et la maintenance des livrables.
Classification de test :
•Tests unitaires: s'assurer que les composants logiciels pris individuellementsont conformes à leurs
spécifications et prêts à être regroupés (un package, une classe, une méthode)
•Tests d’intégration: s'assurer que les interfaces des composants sont cohérentes entre elles et que le
résultat de leur intégration permet de réaliser les fonctionnalités prévues.
•Test Système ou test de validation ou test de qualification: s'assurer que le système complet, matériel
et logiciel, correspond bien à la définition des besoins. Ce test est effectué dans un environnement
proche de l’environnement de production.
•Tests d’acceptation (ou recette): C'est celle au cours de laquelle les différents acteurs du projet se
rencontrent afin de vérifier que le produit est conforme aux attentes formulées:
•Tests alpha: réalisés par le client ou par des users avec le même profil sur le site de développement
•Tests béta: réalisés sur le site du client (de production)
•Test de non régression : vérifier que la correction des erreurs ou les modifications n‘ont pas affecté
les parties déjà développées et testées. Cela consiste à systématiquement rejouer les tests déjà
exécutés.
Les bénéfices d’une usine logicielle :
Gagner du temps, Réduire le risque d’erreur, Faciliter les tests et la recette, Maitriser les dépendances
du projet, Améliorer la qualité des livrables.
Problématique :– Intégration tardive :
• Développer pendant des jours et des semaines sans tester le résultat, Publier du code sans
vérification, publier partiellement, publier du code qui compile mais qui ne marche pas.
-Coût de correction des bugs
Définition de l’intégration continue : est une pratique du développement logiciel qui consiste à intégrer
fréquemment les modifications apportées au code source dans une branche principale partagée par
tous les développeurs. Ces intégrations sont ensuite vérifiées automatiquement à l’aide de tests pour
détecter rapidement les erreurs ou les conflits dans le code.

Principes clés de l’intégration continue :

1. Intégration fréquente : Les développeurs intègrent leurs modifications au moins une fois par
jour pour éviter les conflits complexes liés à des écarts importants entre les branches.
2. Automatisation des builds : À chaque intégration, un processus automatisé (appelé pipeline
CI) compile le code, exécute les tests unitaires, et parfois déploie une version de test.
 3. Détection rapide des erreurs : Si un problème est introduit dans le code (ex. : bug, test
échoué), il est détecté immédiatement, permettant une résolution rapide.
4. Visibilité et collaboration : Les équipes bénéficient d'une vue en temps réel sur l'état du
projet, ce qui favorise la collaboration et réduit les surprises.

Avantages :

 Détection précoce des bugs grâce aux tests automatiques.

 Amélioration de la qualité du code avec des retours rapides après chaque modification.
 Réduction des conflits de fusion en intégrant fréquemment les changements.
 Gain de temps pour les équipes en évitant les longues phases de stabilisation en fin de projet.

Les outils de l’intégration continue :

• Un atelier de développement :– Facilite la production du code source.

• Un gestionnaire de sources :– Partager le code source, documentation, Tracer toutesles

modifications.

• Un système de test unitaires :– Contrôler la validité du code source.– Détecter les régressions.

Un outil de construction: Gérer les dépendances, Automatiser la génération de l’exécutable à partir du

code source.

• Un serveur d’intégration continue : Surveiller les changements apportés au code source, Exécuter
une construction d’intégration à chaque changement du code source.

• Un outil de surveillance de la qualité du code : Inspecter le code source, Établir des métriques sur la
complexité du code, le taux de commentaire, le code dupliqué.

Un repository manager :– Gérer les composants binaires, Les dépendances du projet

• Un outil de communication : Informer en temps réel de l’état de la construction d’intégration.

LE GESTIONNAIRE DE SOURCES

Les objectifs de la gestion de sources :

1. Maintenir un historique des modifications

2. Faciliter la collaboration

3. Assurer la continuité et la récupération

5. Automatiser et intégrer les workflows

6. Améliorer la qualité et la productivité

Les fonctionnalités :

1. Repository (Dépôt)

Un repository est l'endroit où le code source et son historique de versions sont stockés.
2. Version (Révision)

Une version représente un état particulier du projet à un moment donné, après une modification
apportée au dépôt. Chaque version est identifiée de manière unique par un identifiant (SHA dans Git).

3. Branche (Branch)

Une branche est une copie parallèle du code qui permet de développer des fonctionnalités ou de
corriger des bugs sans affecter la branche principale (généralement appelée main ou master).

4. Tag (Étiquette)

Un tag est une référence immuable à une version spécifique du code, généralement utilisée pour
marquer une étape importante, comme une version stable ou une release.

La gestion de sources peut être basée sur deux modèles principaux : le modèle centralisé et le modèle
distribué. Ces modèles déterminent comment le code source et son historique sont stockés, partagés et
gérés.

1. Modèle centralisé

Dans un modèle centralisé, le code source et son historique sont stockés sur un serveur central, et tous
les utilisateurs y accèdent pour effectuer des modifications.

Caractéristiques :

 Un dépôt central unique contient l'ensemble du projet.

 Les développeurs récupèrent le code (checkout) depuis le serveur central et y soumettent leurs
modifications (commit).
 Les utilisateurs doivent être connectés au serveur pour effectuer des opérations comme les
commits ou les mises à jour.

Avantages :

 Simple à configurer et à utiliser pour les petites équipes.

 Permet une gestion centralisée des droits d'accès et des versions.
 Bonne visibilité en temps réel sur l'état du projet.

Inconvénients :

 Dépendance à la disponibilité du serveur central (pas d'accès hors ligne).

 Risque de perte de données en cas de panne ou de corruption du serveur.
 Moins flexible pour les workflows complexes avec de nombreuses branches.

Exemples d'outils :

 Subversion (SVN)
 Perforce

2. Modèle distribué

Dans un modèle distribué, chaque développeur possède une copie complète du dépôt, y compris
l'intégralité de l'historique.
Caractéristiques :

 Les dépôts sont entièrement clonés sur les machines locales des développeurs.
 Les opérations comme les commits, les branches et les fusions peuvent être effectuées
localement, sans connexion au serveur central.
 Les modifications sont ensuite synchronisées avec un dépôt distant via des commandes
comme push ou pull.

Avantages :

 Les développeurs peuvent travailler hors ligne avec toutes les fonctionnalités.
 Plus rapide pour les opérations locales, comme les commits ou les branches.
 Moins de dépendance à un serveur central : si le serveur distant tombe en panne, les dépôts
locaux contiennent toutes les données nécessaires.
 Favorise une collaboration flexible grâce aux branches locales et à la fusion.

Inconvénients :

 Plus complexe à gérer pour les utilisateurs débutants.

 Peut nécessiter plus d'espace de stockage local en raison des copies complètes du dépôt.
 Coordination nécessaire pour synchroniser les modifications avec les dépôts distants.

Exemples d'outils :

 Git
 Mercurial
 Bazaar

Documentation Git :
Initializing Git :- $ git init
Making a Commit :- $ git commit -m “<Enter your message here>”

Status of files and log :- $ git status

Log of a file :- $ git log

Making a new Git Branch :- $ git branch <name of branch>

Checking all available Branches :- $ git branch

Switching to other Branches :- $ git checkout <branch name>

Making a new branch and directly switching to it :- $ git checkout -b <branch name>

Deleting a Branch :- $ git branch -d <branch name>

Merging two Branches :- $ git merge <branch name>

Push local repo to GitHub :- $ git remote add origin <paste copied URL here>

Pull branch from GitHub :- $ git branch –a

Git clone from GitHub :- $ git clone <copied URL>

Git Revert :- Git Revert HEAD :- $ git revert HEAD --no-edit

Git Reset :- $ git reset <commithash>

L’AUTOMATISATION DES BUILDS:

la construction d’un logiciel correspond aux processus qui convertit le code source du projet ainsi que
tout autre élément de configuration sous la responsabilité du développeur dans un logiciel sous sa
forme finale.

Objectifs des outils de construction :

• Simplifier le processus de construction.

• Accélérer la compilation du code source.

• Améliorer la qualité du produit final.

• Fournir un système de construction uniforme.

Les différents types de construction :

• Les termes construction et build seront utilisés indifféremment.

• Build: un ensemble d’activités qui permettent de:

– Compiler le code source.

– Générer de la documentation.

– Tester le code source.

– Inspecter le code source.

– Déployer le logiciel généré à partir du code source.

• Build privé: un build exécuté sur le poste de travail du développeur avant de partager ses
modifications de code source avec l’équipe.

• Peut se restreindre à un sous ensemble de tâches du build en fonction de la taille du projet.

Les différents types de construction :

• Build d’intégration : un build exécuté sur la machine d’intégration continue à chaque nouvelle
publication de modification de code source :

– Peut se restreindre à un sous ensemble de tâches du build en fonction de la taille du projet.

• Build de nuit : un build complet qui exécute toute les tâches prévues dans le processus de build du
logiciel.
– Exécuté sur la machine d’intégration continue en période de baisse d’activité.

• Build de release : Permet de produire une version du logiciel destinée aux utilisateurs finaux :

– Intègre obligatoirement l’exécution des tests d’acceptance.

Présentation de Maven

Maven est un outil de gestion de projets et d’automatisation de construction principalement utilisé

pour les projets Java. Il fournit une manière standardisée de structurer, compiler, tester, et déployer un
logiciel.

 Objectifs principaux :
o Simplifier le processus de construction des projets.
o Gérer automatiquement les dépendances.
o Fournir un cycle de vie standardisé pour les projets logiciels.
 Avantages :
o Portabilité et reproductibilité : Les builds Maven sont identiques quel que soit
l’environnement.
o Grande communauté et nombreux plugins disponibles.

Concepts Maven

1. Project Object Model (POM) :

o Fichier principal du projet ([Link]) où sont définies toutes les informations du
projet, les dépendances, les plugins, et les configurations.
2. Standardisation :
Maven impose une structure standardisée pour les projets, par exemple :
o src/main/java → Code source
o src/main/resources → Fichiers de ressources
o src/test/java → Tests unitaires
o target/ → Résultats de la construction

3. Plugins :
Maven repose sur des plugins pour accomplir des tâches spécifiques comme compiler le code,
exécuter des tests, ou packager l'application.

Vocabulaire Maven

 GroupId : Identifiant du groupe ou de l’organisation (ex. : [Link]).

 ArtifactId : Nom unique de l'application ou module (ex. : mon-projet).
 Version : Version du projet (ex. : 1.0-SNAPSHOT pour une version en développement).
 Goal : Tâche spécifique exécutée par Maven (ex. : compile, package).
 Phase : Étape logique du cycle de vie de la construction (ex. : clean, test, install).
 Repository : Dépôt où sont stockés les dépendances et les artefacts.

Il existe trois cycles de vie implémentés par Maven.• Le cycle de vie Clean:

– Nettoie l’environnement de construction des fichiers générés par la précédenteconstruction.

• Le cycle de vie Default:– Traite la construction et le déploiement du projet.

• Le cycle de vie Site:– Génère la documentation du projet sous forme d’un site web.
• Chacun de ces cycles de vie consiste en un ensemble de phases exécutées dans un ordre spécifique.

Cycle de vie par défaut permettant de construire un projet java Composé de 23 phases.

 clean : Supprime les artefacts des builds précédents.

 validate : Vérifie que le projet est correctement configuré.
 compile : Compile le code source.
 test : Exécute les tests unitaires.
 package : Produit un fichier exécutable (ex. : JAR, WAR).
 verify : Vérifie les critères de qualité.
 install : Installe l’artefact dans le repository local.

 deploy : Publie l’artefact dans un repository distant.

Le cycle de vie Site permet de générer la documentation du projet.

• Composé de 4 phases :

– Pre‐site

– Site

– Post‐site

– Site‐deploy

• Le cycle de vie Clean permet de nettoyer la précédente construction.

• Composé de 3 phases :

– Pre‐clean

– Clean

– Post‐clean

Gestion des dépendances

 Maven gère automatiquement les bibliothèques nécessaires à votre projet grâce au fichier
[Link].

Gestion des Repositories

1. Repository local :
o Stocke les dépendances téléchargées sur votre machine (~/.m2/repository).
2. Repository central :
o Dépôt public de Maven accessible par défaut ([Link]
3. Repository distant :
o Dépôt privé ou tiers pour partager des artefacts spécifiques.
 LE SERVEUR D’INTÉGRATION CONTINUE
JENKINS

Jenkins est un outil open-source populaire conçu pour automatiser et gérer le cycle de vie des projets
logiciels. Il est utilisé principalement pour mettre en œuvre des workflows d’intégration continue (CI)
et de livraison continue (CD).

Caractéristiques clés de Jenkins

1. Interface utilisateur simple : Une interface web intuitive pour configurer et surveiller les
tâches.
2. Support multi-plateformes : Fonctionne sur Windows, Linux, macOS, et autres.
3. Extensibilité via plugins : Permet d’ajouter des fonctionnalités spécifiques en fonction des
besoins du projet.

Avantages de Jenkins

 Automatisation complète du processus de développement.

 Flexibilité et extensibilité grâce à des plugins.
 Support communautaire solide avec mises à jour régulières.
 Intégration facile avec presque tous les outils modernes (Git, Kubernetes, Ansible).

Rôle Description
Réduire les tâches manuelles répétitives dans le cycle de
Automatisation
développement.
Détecter les modifications et déclencher automatiquement des
Surveillance du code
builds/tests.
Orchestration CI/CD Modéliser et exécuter des pipelines complets.
Rapports et feedback Fournir des logs détaillés et des rapports sur les tests/performances.
Intégration avec outils
Connecter des outils comme Git, Maven, Docker, SonarQube, etc.
externes
Collaboration en équipe Améliorer la gestion et la transparence entre les membres de l’équipe.
Gestion multi-
Exécuter des tâches sur différents nœuds ou environnements.
environnements

des grandes fonctionnalités

Fonctionnalité Description

Automatisation des pipelines Modélisation des processus CI/CD avec Jenkinsfile.

Support multi-plateformes Fonctionne sur différents OS et environnements.

Extensibilité via plugins Intégration avec divers outils et technologies.

Intégration avec outils tiers Compatible avec Git, Maven, Docker, etc.

Gestion des déclencheurs Déclenchement via hooks, cron, ou manuellement.

Analyse et rapports Logs détaillés et rapports sur les tests et la qualité.

Notifications et alertes Envoi d'e-mails, notifications Slack, etc.

 Fonctionnalité Description

Gestion des artefacts Archivage et publication des artefacts.

Évolutivité et agents Gestion des tâches sur plusieurs nœuds.

Sécurité et gestion des utilisateurs Contrôle des accès et authentification.

Visualisation des pipelines Vue graphique des étapes CI/CD avec Blue Ocean.

Tests automatisés Exécution des tests pour vérifier la qualité du code.

Support cloud et conteneurs Intégration avec Docker, Kubernetes, et services cloud.

La gestion des plugins Jenkins :

Les plugins constituent le principal moyen pour enrichir le fonctionnalités du serveur d’intégration
continue Jenkins.
• Les plugins Jenkins permettent de répondre aux besoins spécifiques d’une organisation, d’un projet
ou d’un l'utilisateur.
• Il existe différentes catégories de plugins disponibles comme les plugins de :
– Intégration des différents outils de gestion de code source.
– Intégration des différents outils de construction.
– Intégration des différents frameworks de test.
– Intégration des différents frameworks et outils d’analyse de la qualité du code source.
– Intégration des différents outils de gestion des artefacts.
– Authentification et gestion des utilisateurs.
– Administration du serveur Jenkins.
Les JOBS Jenkins peuvent être lancés de différentes manières:
1. Manuellement
2. Selon un crône répétitif (builds réguliers)
3. Utilisation des WebHooks

Pour utiliser les Webhooks dans jenkins, il faut commencer dans la configuration du job par spécifier
dans la partie Buid trigger l’outil de lancement du build à « GitHub hook trigger for GITScm polling»

Qu'est-ce qu'un Pipeline ?

Un pipeline dans Jenkins est une série d'étapes automatisées qui définissent le processus de
développement, de tests et de déploiement d'une application. C'est une manière de structurer et
d'automatiser les différentes phases du cycle de vie d'une application, depuis la récupération du code
source jusqu'au déploiement sur un environnement de production.

Un pipeline est un flux de travail qui peut inclure plusieurs étapes, comme la compilation du code,
l'exécution des tests, la génération des artefacts (par exemple, fichiers JAR ou WAR), et leur
déploiement sur des serveurs de staging ou de production.

Utilisation distribuée de Jenkins :

Jenkins s’est imposé comme un acteur incontournable de l’Intégration Continue et Déploiement en
continue. Dans cette section, nous voyons comment exécuter les jobs Jenkins dans des Agents.
• Contexte : Un host sur lequel il y a un Jenkins ‘master’ et une Machine virtuelle sur laquelle il y a un
agent.
Utilité des distributions de traitement : Cela peut Particulièrement être utile pour différentier différents
environnements :dev , Tes, recette, préprod, prod

Qu'est-ce que Nexus ?

Nexus est un gestionnaire de repositories (dépôts) qui permet de stocker, gérer et distribuer des
artefacts logiciels (fichiers, bibliothèques, dépendances) tout au long du cycle de vie du
développement. Il joue un rôle essentiel dans les pratiques d'intégration continue (CI) et de livraison
continue (CD), en facilitant la gestion des dépendances et le partage des artefacts entre les équipes et
les projets.

 Gestion des artefacts

 Dépôt centralisé

 Gestion des dépendances

 Dépôts privé et public

 Contrôle de version des artefacts

 Accès sécurisé et gestion des utilisateurs

 Référencement des artefacts