Dev Ops

DEV-OPS
Formateur : JEMAL Ahmed

Présentation
Qui suis-je ?
Qui êtes-vous ?
31/05/2022 2
Logistique
Pause en milieu de session
Vos questions sont les bienvenues. N’hésitez pas !
Merci d’éteindre vos téléphones
31/05/2022 3
Objectifs du module
• Comprendre les principes de l’intégration continue

• Gérer les sources avec les SCMs
• Gérer les releases avec Maven et Archiva
• Mettre en place le serveur d’intégration continue Jenkins
• Mettre en place un pipeline d’intégration continue
• Analyser le code source avec SonarQube
31/05/2022 4
Sommaire
• Chapitre 1 : INTRODUCTION À L’INTÉGRATION CONTINUE

• Chapitre 2 : LE GESTIONNAIRE DE SOURCES
• Chapitre 3 : L’AUTOMATISATION DES BUILDS
• Chapitre 4 : LE SERVEUR D’INTÉGRATION CONTINUE JENKINS
• Chapitre 5 : VIRTUALISATION D’ENVIRONNEMENT : DOCKER
• Chapitre 6 : GESTION DES LIVRABLES
• Chapitre 7 : L’AUTOMATISATION DES TESTS
• Chapitre 8 : GESTION DE LA QUALITÉ DU CODE
31/05/2022 5
INTRODUCTION À L’INTÉGRATION CONTINUE
Introduction À L’intégration Continue
• Agenda
– Définition de l’intégration continue
– Les principes de l’intégration continue
– Les prérequis de l’intégration continue
– Les différents outils de l’intégration continue
– Mise en place de l’environnement d’intégration continue
31/05/2022 7
Approche naïve de production du logiciel
• Je partage mes sources.

• Je développe du code dans un IDE.
• Je compile mon code dans mon IDE.
• Je génère le livrable via mon IDE.
• Je déploie le livrable.
• Je teste mon livrable.
• Je mets en production mon livrable.
31/05/2022 8
Approche naïve de production du logiciel
• Je ne comprends pas, ça marche sur mon poste !?
« Il est humain de se tromper,

mais persévérer (dans l'erreur) est diabolique. »
31/05/2022 9
Approche naïve de production du logiciel :
Le constat
• Le développement doit être incrémental pour gérer les incertitudes.
• Le développement doit être industrialisé pour gérer la complexité.
31/05/2022 10
Le besoin de disposer d’une usine
logicielle
• 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.
31/05/2022 11
Le besoin de disposer d’une usine
logicielle
31/05/2022 12
Les bénéfices d’une usine logicielle
• Gagner du temps, car tout est automatisé.

• Réduire le risque d’erreur, car il n’y a pas d’intervention humaine.
• Pérenniser la procédure, car on ne dépend pas du savoir d’un
développeur, ni de ce qu’il a installé sur son ordinateur !
• Faciliter les tests et la recette, avec la mise à jour automatique des
serveurs de test et la création d’un environnement de recette remis à
zéro à chaque livraison.
• Maitriser les dépendances du projet.
• Améliorer la qualité des livrables.
31/05/2022 13
Problématique (1) – 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.
• Découvrir des régressions à la dernière minute avant les livraisons.
Module1
Module2
Modulei
Développement Intégration
31/05/2022 14
Problématique (2) – Coût de correction
des bugs
Les 5% de bugs découverts après la release représentent 95% des coûts de

correction
31/05/2022 15
La solution : L’intégration au plus tôt
31/05/2022 16
La solution : L’intégration au plus tôt
Intégration Intégration Intégration Intégration Intégration Intégration
Module1
Module2
Modulei
Développement
31/05/2022 17
Définition de l’intégration continue
• « … une pratique de développement logiciel où les membres d’une équipe intègrent

leur travail fréquemment, habituellement chacun au moins une fois par jour – ce qui
entraine plusieurs intégrations par jour. Chaque intégration est validée par une
construction ‘build’ automatique (ce qui inclut les tests) pour détecter les erreurs
d’intégration aussi vite que possible ... »
Martin Fowler
31/05/2022 18
Les principes de l’intégration continue
• Gestion centralisée du code source

– Maintenir un dépôt unique de code source.
– Le code source est partagé entre les membres de l’équipe via un outil de gestion
de source.
31/05/2022 19
• Construction automatique
– La construction englobe l’ensemble des actions souhaitées prenant en entrée des
fichiers sources pour produire un résultat souhaité.
– La construction doit être faite de sorte qu’elle soit automatisable.
– L’ensemble des étapes de la construction doit être réalisable par un outil de
construction logicielle.
– L’automatisation de la construction permet de lancer via une commande simple
un ensemble de processus complexes qui s’enchainent dans un ordre précis.
31/05/2022 20
• Construction auto-testante
– Les tests font partie de la construction.
– Les tests doivent être exécutables dans un mode automatique pour qu’ils
puissent être pris en compte lors de la construction du logiciel.
– Les tests permettent de valider le bon fonctionnement du livrable produit par la
construction.
– L’échec d’un test entraine l’échec de la construction.
– Les tests doivent être passant à 100%.
31/05/2022 21
• Construction de courte durée

– La durée de la construction détermine la fréquence d’exécution de la
construction.
– Plus la construction est rapide plus il sera possible de lancer des intégrations
dans la journée et de savoir :
• Si le code source compile toujours.
• Si les tests sont toujours passants.
• Si tous les composants du logiciel fonctionnent correctement ensemble.
• Si le logiciel se déploie toujours correctement, etc.
– En cas de problème détecté
il sera plus facile de corriger les anomalies.
31/05/2022 22
• Toute modification du logiciel est intégrée

– Toute modification d’objet de configuration du logiciel doit être intégrée et
testée sur la machine d’intégration continue pour valider son impact sur le
livrable.
31/05/2022 23
• Environnement d’intégration ISO production

– L’environnement de test du livrable produit par la construction doit être le plus
proche de l’environnement de production, voir ISO production.
– Les écarts entre l’environnement de test et l’environnement de production
peuvent conduire à un échec de déploiement du logiciel en production, même si
le déploiement et les tests étaient concluant en environnement d’intégration.
• Architecture matérielle.
• Version de système d’exploitation.
• Version de machine virtuelle.
• Etc.
31/05/2022 24
• Tout le monde doit être au courant de ce qui se passe

– Le déroulement des processus de construction, de test et de déploiement doit
être visible à tous les contributeurs du projet.
31/05/2022 25
• Synthèse des principes

– Gestion centralisée du code source.
– Construction automatique.
– Construction auto-testante.
– Construction de courte durée.
– Toute modification du logiciel est intégrée.
– Environnement d’intégration ISO production.
– Tout le monde doit être au courant de ce qui se passe.
31/05/2022 26
Les prérequis de l’intégration continue
• Publication régulière du code source

– Plus la quantité de codes publiés est grosse plus le risque de conflit augmente.
– La publication régulière du code source :
• Réduit le risque de conflit.
• Facilite l’identification de la modification à l’origine du problème.
– Pour pouvoir publier régulièrement le code source il faut :
• Publier les modifications apportées à la fin de chaque tâche de développement.
• Faire des petits changements et ne pas apporter des changements à plusieurs composants
dans une seule tâche.
➔ Chaque développeur doit publier ses modifications du code source au
moins une fois par jour.
31/05/2022 27
• Exécuter des constructions privées
– Pour éviter les constructions cassées, le développeur doit exécuter des

constructions privées sur son poste de travail.
– Permet de détecter et corriger les erreurs de compilation avant la publication du

code source modifié par le développeur.
– Permet de détecter et corriger les tests en échec avant la publication du code

source modifié.
31/05/2022 28
• Ne pas publier du code qui ne compile pas

– La publication de code qui ne compile pas implique systématique l’échec de la
construction.
– L’usine logicielle est alors mise hors service.
31/05/2022 29
• Réparer les constructions cassées immédiatement
– Une construction est dite cassée en cas de problème empêchant son succès :
• Erreur de compilation.
• Test en échec.
• Problème de déploiement.
• Etc…
– La réparation des constructions cassées est une urgence pour le projet.
– Le responsable du commit à l’origine de l’échec de la construction porte la
responsabilité de la réparation.
31/05/2022 30
• Synthèse des prérequis

– Publication régulière du code source.
– Exécuter des constructions privées.
– Ne pas publier du code qui ne compile pas.
– Réparer les constructions cassées immédiatement.
31/05/2022 31
Les bénéfices de l’intégration continue
• Réduire les risques – Détection tardive des anomalies

– Les anomalies sont détectées et corrigées au plus tôt :
• Les anomalies ont plus de chance d’être détectées au moment de leur introduction dans le
code source.
• Réduit le risque de la détection tardive des anomalies.
31/05/2022 32
• Réduire les risques – Non qualité

– La qualité logicielle est mesurable via des métriques actualisées en continu :
• Suite à l’exécution des tests automatiques et de l’inspection du code source.
• Réduit le risque de la non qualité logicielle.
31/05/2022 33
• Réduire les risques – Logiciel non déployable

– Le logiciel est construit et déployé dans un environnement à l’image de son
environnement de production :
• La machine d’intégration continue est une référence.

• Réduit les risques de la détection tardive des dépendances par rapport au système
d’exploitation, variables d’environnement, les options de compilation, librairies tierces, etc.
– Le livrable du logiciel est reproductible dans le temps et dans l’espace.
– Je ne comprends pas, ça marche sur mon poste !?
31/05/2022 34
• Automatiser les tâches manuelles répétitives

– Garantit que :
• Les processus sont toujours exécutés de la même manière.
• Les processus sont toujours exécutés dans le même ordre.
• Les processus sont exécutés à chaque changement du code.
– Assure un gain de temps, d’effort et de budget.
– Permet à l’équipe de se concentrer sur des tâches à forte valeur ajoutée.
31/05/2022 35
• Générer des versions intermédiaires du logiciel
– Une version intermédiaire du logiciel est générée à chaque intégration :

• Une version déployable et testable du produit peut être générée à tout moment.
• Améliore la confiance de l’équipe de développement par rapport aux changements apportés.
• Améliore la confiance du client par rapport à la pertinence des réalisés.
– Permet de s’immuniser contre l’effet tunnel, première cause d’échec des projets
informatiques.
31/05/2022 36
• Améliorer la visibilité projet
– Prise de décision efficace :

• La prise de décision se fait sur la base d’informations actualisées en continu et partagées
dans l’équipe de développement.
– Mesure des tendances :

• Observation de l’évolution des indicateurs de la qualité logicielle.
• Constructions réussies.
• Tests passants.
• Couverture des tests.
• Etc…
31/05/2022 37
• Synthèse des bénéfices
– Réduire les risques – Détection tardive des anomalies.

– Réduire les risques – Non qualité.
– Réduire les risques – Logiciel non déployable.
– Automatiser les tâches manuelles répétitives.
– Générer des versions intermédiaires du logiciel.
– Améliorer la visibilité projet.
31/05/2022 38
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, etc.
– Tracer toutes les modifications.
• Un système de test unitaires :
– Contrôler la validité du code source.
– Détecter les régressions.
– Peut être lancé en mode automatique ou en mode manuel.
31/05/2022 39
• 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é, etc.
31/05/2022 40
• Un repository manager :
– Gérer les composants binaires.
– Les dépendances du projet
– Les artefacts produits par le projet.
• Un outil de communication :
– Informer en temps réel de l’état de la construction d’intégration.
31/05/2022 41
Environnement d’intégration continue
31/05/2022 42
Sommaire

31/05/2022 43
LE GESTIONNAIRE DE SOURCES
Le Gestionnaire De Sources
• Agenda
– Les objectifs de la gestion de sources
– Les fonctionnalités
– Les différents gestionnaires de sources
– Les problématiques d’intégration des changements
31/05/2022 45
Les objectifs de la gestion de sources
• Gérer les activités de lecture, écriture et fusion sur les sources du projet.
• Conserver un historique des modifications apportées aux sources:
– Par qui, quand, quoi ?
• Permettre de revenir en arrière en cas de besoin.
• Permettre de travailler en équipe sur les mêmes sources d'un projet.
– Gérer les accès concurrents.
– Gérer les conflits.
• Permettre de travailler simultanément sur plusieurs versions d’un
logiciel.
31/05/2022 46
Les objectifs de la gestion de sources
• Permet de retrouver un fichier source supprimé.

• Fonctionne avec tout type de fichier (.txt, .php, .java, .jpg, .exe, …).
• Garantir la sécurité de la configuration du logiciel:
– Autorisation.
– Confidentialité.
– Intégrité.
– Disponibilité.
31/05/2022 47
Les fonctionnalités : Repository
• Un dépôt (local ou distant) qui contient toutes

les versions des sources du projet.
• Une base de données des changements apportés

à la configuration du logiciel.
• Le dépôt a une structure arborescente :
31/05/2022 48
Les fonctionnalités : Version
• Une version ou révision est une instance d'un fichier source qui est
strictement distincte des autres instances.
• Les versions peuvent se succéder de manière linéaire dans le temps.
• En cas de modifications concurrentes d’une version, des splits et des

merges peuvent avoir lieu.
31/05/2022 49
Les fonctionnalités : Branche
• Permet de développer en
parallèle plusieurs versions du
logiciel.
• Permet de corriger un
problème sur une ancienne
version du logiciel.
• Permet de fusionner après
une divergence.
31/05/2022 50
Les fonctionnalités : Tag
• Donner un nom explicite à une

version du logiciel pour pouvoir
y accéder facilement.
• Permet de définir les versions

du projet.
• Permet de nommer des

branches.
31/05/2022 51
Les différents gestionnaires de sources :
Modèle centralisé (1)
• Centralized Version Control System – CVCS
31/05/2022 52
• Le dépôt est stocké dans un endroit partagé.
• Chaque développeur a une copie de travail du dépôt.
• Utilise le mode de verrouillage pour gérer les développements
concurrents sur un même fichier source.
• Il est nécessaire d’avoir la connexion au dépôt pour commiter ses
modifications ou mettre à jour sa copie de travail.
31/05/2022 53
• Avantages :
– Technologie éprouvée.
– Structure simple.
– Gestion et utilisation simples à mettre en œuvre.
– Largement disponible (IDE, Forges).
• Faiblesses :
– Très sensible aux pannes, impossible de travailler hors connexion.
– Inadapté aux très grands projets, le temps de mise à jour du dépôt est trop long.
31/05/2022 54
Modèle centralisé – Exemple Subversion
• Créé en 2000 pour remplacer CVS.
• Logiciel libre.
• Multi-plateforme (linux, windows, MacOS, ...).
• Documentations très riches, forums actifs.
• Implémente des protocoles réseaux sécurisés
(HTTPS) .
• Interfaces graphiques.
• Intégré dans plusieurs IDE tel que Eclipse.
31/05/2022 55
Les différents gestionnaires de sources:
Modèle distribué (1)
• Distributed Version Control System – DVCS
31/05/2022 56
• Chaque développeur a sa copie avec des branches et des tags privés.

• Utilise le mode de fusion pour gérer les développements concurrents
sur un même fichier source.
31/05/2022 57
• Avantages :
– Travail déconnecté, accès aux dépôts en local sur le poste de travail du
développeur.
– Moins sensible aux pannes.
– Rapidité, le réseau n’est utilisé que pour les opérations de synchronisation.
– Branches privées.
– Modèle de développement autorisé très souple.
• Faiblesses :
– Gestion et utilisation plus compliquées.
– Risque de divergence, peut devenir très complexe structurellement.
31/05/2022 58
Modèle distribué – Exemple Git
• Créé en 2005 par Linus Torvalds pour la gestion des sources du noyau
Linux.
• Logiciel libre.
• Multi-plateforme (linux, windows, MacOS, ...).
• Documentations très riches, forums actifs.
• Implémente des protocoles réseaux sécurisés (HTTPS) .
• Interfaces graphiques.
• Intégré dans plusieurs IDE tel que Eclipse.
• Ne stocke que le delta entre deux versions d’un objet.
31/05/2022 59
Labs
Installation et utilisation de SVN

Installation et utilisation de GIT
Problématiques de fusion des
changements
• Plus la quantité de codes publiés est grosse plus le risque de conflit
augmente.
31/05/2022 61
Problématiques de fusion des
changements
• La publication régulière du code source :
– Réduit le risque de conflit.
– Facilite l’identification de la modification à l’origine du problème.
• Pour pouvoir publier régulièrement le code source il faut :
– Publier les modifications apportées à la fin de chaque tâche de développement.
– Faire des petits changements et ne pas apporter des changements à plusieurs
composants dans une seule tâche.
31/05/2022 62
Problématiques de fusion des changements:
Bonnes pratiques
• Essayez de travailler le plus possible avec des fichiers texte et le moins
possible avec des fichiers binaires.
• Faites des updates le plus souvent et régulièrement possible, et
obligatoirement avant de commencer à travailler sur un fichier.
• Faites des commits réguliers, dès que vous avez fini de travailler sur un
fichier, et si la tâche prend du temps, un commit intermédiaire
permettra de sauvegarde votre travail.
• Prévoyez un planning pour savoir qui peut travailler et quand sur les
fichiers binaires notamment.
31/05/2022 63
Labs
Gestion de conflit GIT

Sommaire

31/05/2022 65
L’AUTOMATISATION DES BUILDS
L’automatisation Des Builds
• Agenda
– Qu’est ce que la construction d’un logiciel
– Objectifs des outils de construction
– Prérequis d'une construction automatisable
– Différents types de constructions
– Construction logicielle avec Maven
31/05/2022 67
Qu’est ce que la construction d’un logiciel
• Dans le contexte du développement logiciel, 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.
• Comporte :
– La compilation du code source.
– Le packaging des fichiers compilés dans un format compressé tel que jar, zip, war, etc.
– La production des installeurs.
– Etc…
• Terme apparu avec la création de l’outil make pour les systèmes Unix en 1977.
31/05/2022 68
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:
– La maitrise de la construction d’un projet avec un outil donné permet de faciliter
la maitrise des constructions des projets utilisant le même outil.
31/05/2022 69
Prérequis d'une construction
automatisable
• Une construction logicielle est dite automatique quand toutes ses
étapes :
– Sont répétables.
– Ne nécessitent aucune intervention humaine.
– Peut être exécutée à tout moment sans besoin d’information autre que « où est
stocké le code source du projet »?
31/05/2022 70
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.
31/05/2022 71
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.
31/05/2022 72
Construction logicielle avec Maven :
Présentation de Maven
• Un outil de construction d'application Java:
– Génère une application « déployable » à partir d'un code source.
– Compile.
– Exécute des tests.
• Un outil de gestion de développement qui permet de gérer :
– Documentation & Rapports.
– Site web, etc…
• Projet Apache :
– http://maven.apache.org
– Développé en Java
31/05/2022 73
Construction logicielle avec Maven : Les
concepts Maven
• Privilégier la standardisation à la liberté, Convention over Configuration :
– Structure standard des répertoires d'une application
– Cycle de développement standard d'une application
• Factoriser les efforts :
– Un dépôt global regroupant les ressources / bibliothèques communes.
– Des dépôts locaux.
– Un dépôt personnel.
• Multiplier les possibilités:
– Une application légère.
– De nombreux plugins, chargés automatiquement au besoin.
31/05/2022 74
Vocabulaire Maven
• Plugin :
– Extension de l'application de base, proposant un ensemble de goals.
– Le noyau de Maven constitue un framework d’exécution de plugin.
• Goal :
– Tâche proposée par un plugin permettant de lancer un certain nombre d'action.
– Invoqué par mvn plugin:but.
– Paramétré par -Dparam=valeur.
• Maven Project Lifecycle:
– Détermine clairement comment est construit un artefact.
31/05/2022 75
Vocabulaire Maven
– Une séquence de phases qui permettent d'ordonner des groupes de goals.
• Phase:
– Étape du cycle de développement d'un logiciel, généralement associée à des
buts.
– Exécutée avec la commande mvn phase.
• Artifact:
– Application dont le développement est géré via Maven.
• POM:
– Un projet est décrit par un fichier XML mettant le projet en place.
– Ce fichier est appelé POM pour Projet Object Model.
31/05/2022 76
Exemples de plugins et goals Maven
• Plugin archetype:
– Usage: pour créer de nouveaux projets standards.
– Goals: generate, create.
• Plugin compiler:
– Usage: pour la compilation de code java.
– Goals: compile.
• Plugin jar:
– Usage: pour générer des artefacts de type jar.
– Goals: jar, test-jar.
• Plugin surefire:
– Usage: pour l'exécution des tests
– Goals: test.
31/05/2022 77
Construction logicielle avec Maven : Cycle
de vie, phases et goals
• Exécution du cycle de vie:
– Exécution des phases associées.
• Exécution d'une phase:
– Exécution des goals associés.
– Exécution de la phase précédente.
• Exécution d'un goal:
– Exécution du goal seulement.
31/05/2022 78
Construction logicielle avec Maven : Cycle
de vie
• 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édente
construction.
• 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,
31/05/2022 79
Construction logicielle avec Maven : Le
cycle de vie Default
• Cycle de vie par défaut permettant de construire un projet java.
• Composé de 23 phases.
– Validate : valide que le projet est correct et que les informations nécessaires à la
construction sont disponibles.
– Compile : compile le code source du projet.
– Test : Teste le code source compilé du projet.
– Package : génère le livrable dans le format attendu.
– Verify : vérifie les résultats des tests d’intégration.
– Install : installe le livrable dans un dépôt local.
– Deploy : installe le livrable dans un dépôt distant.
31/05/2022 80
cycle de vie Clean
• Le cycle de vie Clean permet de nettoyer la précédente construction.
• Composé de 3 phases :
– Pre-clean
– Clean
– Post-clean
• La commande mvn clean supprime le répertoire de la construction.
• Le comportement de cette commande peut être personnalisé en
précisant le goal à exécuter mvn clean:goal.
31/05/2022 81
cycle de vie Site
• 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
31/05/2022 82
Construction logicielle avec Maven : POM
– Structure du fichier
31/05/2022 83
- XML
31/05/2022 84
- Minimaliste
• Compile le code source du projet.
• Exécute les tests.
• Génère un package jar.
• Déploie le package jar généré dans un dépôt local.
31/05/2022 85
- Coordonnées
• GroupId :
– En général, le nom du domaine à l'envers.
• ArtifactId :
– Nom de l’artefact généré par le projet.
• Version :
– majorVersion.minorVersion.incrementalVersion-qualifier.
– Permet d’identifier le numéro du build du projet.
• Packaging :
– Type de paquetage à produire (jar, war, ear, etc.).
• Le tuple GroupId, ArtifactId, Version constitue l’identifiant de l’artefact du
projet.
31/05/2022 86
Structure des répertoires projet
■ pom.xml Exemple de projet :
■ src
– main
■ java
■ resources
– test
■ java
■ resources
■ target
– classes
– test-classes
31/05/2022 87
Gestion des dépendances
• Un des points forts de Maven qui simplifie le développement des
projets Java.
• Permet une construction facile du classpath.
• Une résolution des dépendances transitives :
– Permet de récupérer automatiquement les dépendances d’une dépendance et
de les inclure dans le projet.
– Il n’y a pas de limites sur le nombre de niveaux de résolution des dépendances.
– Possibilité d’exclure des dépendances récupérées par transitivité.
31/05/2022 88
• Spécifiées par :
– Un identifiant (group/artifact/version)
– Une portée (scope).
• Version
– 1.2.3 : si possible 1.2.3 si non plus récent.
– [1.2,1.3] : de 1.2 à 1.3 inclus.
– (1.2,1.4) : à partir de 1.2, mais avant 1.4.
– (,2.0) : antérieur à 2.0.
– [1.4,] : à partir de 1.4.
– [1.2.3] : 1.2.3 absolument.
31/05/2022 89
• Portée
– Compile : nécessaire à la compilation, et inclus
dans le paquetage (portée par défaut).
– Provided : nécessaire à la compilation, non
packagé (ex : Servlets).
– Runtime : nécessaire pour exécution et test,
mais pas compilation (exemple : driver jdbc).
– Test : nécessaire uniquement pour les tests
(exemple : junit).
– System : comme provided + chemin dans le
système de fichiers à préciser.
31/05/2022 90
Gestion des Repositories
• Gère les artefacts des projets ainsi que leurs dépendances.
• Peut stocker des artefacts de type jar, war, ejb, rar, ear.
• Deux types de repository existent :
– Local.
– Remote.
• Un repository peut être snapshot ou release.
• Repositories par défaut :
– Local sous le home de l’utilisateur.
– http://repo.maven.apache.org/maven2/
31/05/2022 91
Gestion des Repositories
31/05/2022 92
Labs
Installation et utilisation de Maven

Sommaire

31/05/2022 94
LE SERVEUR D’INTÉGRATION CONTINUE
JENKINS
Le Serveur D’intégration Continue Jenkins
• Agenda
– Le serveur Jenkins
– Le rôle du serveur Jenkins
– Les grandes fonctionnalités
– Configuration du serveur Jenkins
– La gestion des plugins Jenkins
– Les plugins les plus utilisés
– Gestion des utilisateurs et des autorisations
– Gestion de l’espace disque
– Le monitoring du serveur Jenkins
– Création de Job Jenkins
31/05/2022 96
Le serveur Jenkins
• Jenkins a été créé par Kohsuke KAWAGUCHI en 2004 sous le nom Hudson.
• Jenkins est un fork du serveur Hudson depuis 2011.
• Jenkins est développé en Java et Groovy.
• Jenkins s’exécute dans un conteneur de Servlet de type Apache Tomcat.
• Jenkins est perçu comme le serveur d’intégration continue le plus populaire
du marché.
• Jenkins est un logiciel libre, publié sous licence MIT.
• Jenkins est supporté par une grande communauté et une documentation
complète.
• Le site de référence de Jenkins est : https://jenkins.io/
31/05/2022 97
Le rôle du serveur Jenkins
• Le serveur d'intégration continue est l’orchestrateur de l’usine logicielle.

• Il permet de faire collaborer plusieurs outils contribuant à l’exécution du
processus d’intégration continue.
• Jenkins est un outil open source simple, extensible et facile à utiliser qui
fournit des services d’intégration continue pour le développement des
applications.
• Jenkins est un outil de construction continue qui permet aux équipes de
se concentrer sur leur travail pour créer de la valeur métier en
automatisant les processus de construction, de gestion des artefacts et
de déploiement.
31/05/2022 98
• Développement normal :
• Développement En Intégration continue
31/05/2022 99
• Jenkins peut être utilisé par des équipes de toutes tailles, pour des
projets dans une grande variété de langages de programmation, y
compris Java, .NET, Ruby, Groovy, Grails, PHP etc.
• L'interface utilisateur de Jenkins est simple, intuitive.
31/05/2022 100
Les grandes fonctionnalités
• Jenkins est l'un des serveurs d’intégration continue les plus populaires
sur le marché en raison de :
– Installation facile sur différents systèmes d'exploitation.
– Mise à jour facile, Jenkins a des cycles de livraison très rapides.
– Facilement configurable via une interface graphique d’administration.
– Facilement extensible avec l'utilisation de plugins tiers, plus de 1400 plugins
maintenus par une communauté hyperactive permettant la construction, le
déploiement et l'automatisation de tout type de projet.
– Interface utilisateur simple et facile à utiliser.
31/05/2022 101
• Infiniment scalable grâce à l'architecture maître-esclave qui

prend en charge la génération distribuée de build pour
réduire les charges sur le serveur d’intégration continue.
• Jenkins prend en charge le build de projets de type Apache

Maven, Apache Ant, Gradle, Freestyle, etc.
31/05/2022 102
• Jenkins prend en charge la planification de builds, basée sur les

expressions cron ou déclenchée par un commit dans un système de
contrôle de version.
• Jenkins permet la supervision de l’exécution de tâches, telle que la
construction d'un projet.
• Jenkins prend en charge les outils de gestion de code source tels que
Git, Subversion, CVS, StarTeam , ClearCase, AccuRev, Team Foundation
Server, etc…
31/05/2022 103
• Jenkins permet de lancer l’exécution de commandes Shell linux et Windows

lors des étapes de pré-build et de post-build.
• Jenkins supporte l’exécution des tests et l’analyse de la qualité du code
source. Les résultats sont disponibles sous forme de rapport et de graphique.
• Jenkins prend en charge la publication des artefacts projets dans différents
gestionnaires de dépôts d’artefact tel que Apache Archiva, Artifactory,
Sonatype Nexus, etc.
• Jenkins supporte le déploiement directement dans les environnements de
test ou de production.
• Jenkins supporte l’envoi de notifications liées à l'état du build.
31/05/2022 104
• Jenkins supporte la gestion des permissions avec la possibilité de

raccordement à un Ldap d’entreprise.
• Jenkins supporte la surveillance de la santé du serveur.
31/05/2022 105
Qu'est-ce que Jenkins ne fait pas?
• Le café
• Traiter les Jiras (un système de suivi de bugs) à votre place
• Ecrire les tests à votre place
• Relire le code des autres à votre place
31/05/2022 106
Installation du serveur Jenkins
• Comment installer jenkins:
I. Docker
II. Linux : via un package/repo
III. Windows : via un installateur
IV. A la main via « java –jar » avec « systemd »
31/05/2022 107
I. Docker
• Nous avons le choix entre deux images à récupérer :

– JENKINS de base, celle à priori officielle (https://hub.docker.com/_/jenkins)
– JENKINS dite totalement fonctionnelle, ici, officielle aussi, mais mise à jour
régulièrement. (https://hub.docker.com/r/jenkins/jenkins/)
• Avantages
– Installation rapide et simple.
– Indépendant de la distribution Linux et de sa version.
– Facilement déplaçable (avec un orchestrateur).
31/05/2022 108
I. Docker
• Inconvénients
– Si on veut que Jenkins lance des images docker, ça fera du docker dans docker
(pas si simple) et/ou peut apporter des risques de sécurité
– On ne peut a priori pas mettre à jour Jenkins via son outil intégré
31/05/2022 109
II. Linux
• via les repositories .deb/.rpm

– Pour RedHat/CentOS :
• Mise en place du repository
– wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
– rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
• Installation
– yum install jenkins
• Activation du service
– systemctl enable jenkins
– systemctl start jenkins
31/05/2022 110
II. Linux
• via les repositories .deb/.rpm

– Pour Debian / Ubuntu :
• Mise en place du repository
– wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
– sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list’
• Installation
– sudo apt-get update
– sudo apt-get install jenkins
• Activation du service
– systemctl enable jenkins
– systemctl start jenkins
31/05/2022 111
II. Linux
• Mise en place du reverse proxy avec Nginx

– Créer un nouveau virtual host pour Jenkins :
• vi /etc/nginx/conf.d/jenkins.conf
– et y mettre ceci :
upstream app_server { server {
server 127.0.0.1:8080 fail_timeout=0; listen 80;
server_name jenkins.cloud-devops.fr;
} location / {
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
31/05/2022 112
II. Linux
• Mise en place du reverse proxy avec Nginx

– On relance le service nginx :
• systemctl restart nginx
– et on peut accéder à Jenkins via l’url
• http://jenkins.cloud-devops.fr/
• Avantages
– Mises à jour de sécurité gérées via yum ou apt, comme le reste des outils de la
distribution.
– On peut choisir un repo LTS, pour n’avoir que les mises à jour en LTS.
– Installation rapide et simple.
31/05/2022 113
II. Linux
• Avantages
– La version est un peu plus récente que sous Docker (au moment ou j’ai testé :
2.164.2 au lieu de 2.121.1), pour une raison que j’ignore
– Tout le paramétrage, les données et logs sont facilement accessibles sur le
filesystem, et « rangés » suivant les normes de la distribution.
– On peut facilement changer les paramètres de lancement de Jenkins (dans
/etc/sysconfig/jenkins sous CentOS, dans /etc/default/jenkins sous
Debian/Ubuntu).
31/05/2022 114
• Pour les utilisateurs de Windows, il existe un installateur Windows pour

Jenkins. L'installateur se présente sous la forme d'un package MSI pour
Jenkins. Dans la plupart des cas, tout ce que vous aurez à faire sera de
lancer le fichier jenkins-x.x.msi.
• L'installateur MSI est livré avec une version du JRE intégré, il n'est donc
pas nécessaire d'avoir une version de Java installée.
31/05/2022 115
31/05/2022 116
31/05/2022 117
• Avantages
– La version est un peu plus récente que sous Docker (au moment ou j’ai testé :
2.164.2 au lieu de 2.121.1), pour une raison que j’ignore
– Tout le paramétrage, les données et logs sont facilement accessibles sur le
filesystem, et « rangés » suivant les normes.
– On peut facilement changer les paramètres de lancement de Jenkins (dans
/etc/sysconfig/jenkins sous CentOS, dans /etc/default/jenkins sous
Debian/Ubuntu).
31/05/2022 118
IV. A la main via « java –jar »
• On commence par télécharger la version War de Jenkins du site de

référence https://get.jenkins.io/war-stable/2.332.1/jenkins.war :
– Directement à partir d’un navigateur
– En utilisant la commande « wget » ou « curl »
• On déploie ensuite Jenkins sur Tomcat dans le dossier Webapps avant
de le démarrer ou on le lance via la command:
– Java –jar jenkins,jar
31/05/2022 119
Labs
Lancement et Configuration du serveur Jenkins

Configuration du serveur Jenkins
• La configuration du serveur Jenkins est accessible aux administrateurs

du serveur.
• La vue « Administrer Jenkins » permet d’accéder à :
– La configuration du système.
– La configuration globale des outils.
– La configuration globale de la sécurité du serveur.
– La gestion des plugins.
– Les informations, les logs et les statistiques d’utilisation du système.
• La vue « Administrer Jenkins » est le point central des tâches de
configuration du serveur Jenkins.
31/05/2022 121
Configuration du serveur Jenkins
• La vue «Administrer Jenkins » est accessible via le menu « Administrer

Jenkins ».
31/05/2022 122
Configuration du serveur Jenkins :
Configuration globale des outils (2)
• La vue par défaut « Configuration globale des outils » permet de
configurer les installations des JDK et Maven qui peuvent être utilisées
par Jenkins pour construire des projets.
• Cette vue peut être enrichie avec l’installation des plugins pour
accomplir des tâches spécifiques.
31/05/2022 123
Labs
Configuration du JDK et Maven du serveur Jenkins

La gestion des plugins Jenkins
• Les plugins constituent le principal moyen pour enrichir les

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 plus de 1400 plugins qui peuvent être installés sur Jenkins.
• 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.
31/05/2022 125
La gestion des plugins Jenkins (2)
– 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 plugins peuvent être téléchargés automatiquement, avec leurs
dépendances, à partir du Centre de mise à jour Jenkins.
• Le centre de mise à jour est un service exploité par le projet Jenkins qui
fournit un inventaire des plugins open source qui ont été développés et
maintenus par divers membres de la communauté Jenkins.
31/05/2022 126
La gestion des plugins Jenkins (3)
• Un plugin installé dans Jenkins se présente comme un paramètre ou un

élément configurable dans :
– La configuration du système Jenkins.
– La configuration d’un job Jenkins.
• La liste de tous les plugins Jenkins est disponible sur le site
https://plugins.jenkins.io
31/05/2022 127
Les plugins les plus utilisés
• Le plugin Git: permet à Jenkins d’utiliser GIT comme serveur de gestion de

code source.
• Le plugin GitLab: Ce plugin est un déclencheur de construction qui permet à
GitLab de déclencher des constructions Jenkins lorsque le code est publié ou
qu'une requête de fusion est créée.
• Le plugin Maven integration: permet à Jenkins d’intégrer Apache Maven
comme outil de construction des projets Java.
• Le plugin Maven Release: permet l’exécution des cibles Maven
release:prepare et release:perform.
• Le plugin Workspace Cleanup: ce plugin supprime l'espace de travail avant ou
après la terminaison de la construction.
31/05/2022 128
Labs
Installation des plugins de Git et Maven Integration

Création de Job Jenkins
• La construction d’un projet est assurée par un Job dans Jenkins.

• La configuration du Job détermine comment le projet sera construit:
– Comment compiler le projet.
– Comment tester le projet.
– Comment empaqueter le projet.
– Comment déployer le projet.
– Etc…
• La configuration d’un Job comporte les éléments suivants:
– La configuration de la gestion de code source.
– La configuration des éléments déclencheurs de la construction du projet.
31/05/2022 130
Création de Job Jenkins (2)
– La configuration de l’environnement de la construction du projet.

– Les étapes à dérouler avant de lancer la construction du projet.
– La configuration de l’outil de construction du projet.
– Les étapes à dérouler après la fin de la construction du projet
31/05/2022 131
• La création de nouveau Job Jenkins est disponible via la vue « Nouveau

Item ».
31/05/2022 132
• La section « General »
permet de configurer
des informations
générales sur le projet,
telles que son nom et
une description, le
nombre de
constructions à
conserver en
historique.
31/05/2022 133
• La section « Gestion
de code source »
permet de configurer
l’accès au dépôt Git
contenant le code
source du projet.
31/05/2022 134
• La section « Ce qui
déclenche le build » permet
de configurer l’élément
déclencheur de
construction.
– Une construction est
programmée toutes les 5
minutes.
31/05/2022 135
• Les sections « Pre Steps »

et « Build » permettent de
configurer les étapes de
construction Maven.
Indiquez le nom du fichier
de construction.
31/05/2022 136
• Sauvegarder la configuration
du Job et cliquer sur le bouton
« Lancer un build » pour lancer
la construction du projet
immédiatement.
– L’avancement de la construction
du projet est visible dans la
widget « Historique des builds ».
31/05/2022 137
• Les logs produits lors de l’exécution de la construction du projet sont

accessibles via la sortie de console.
31/05/2022 138
• Les résultats de l’exécution des tests unitaires sont accessibles via le lien
« Derniers résultats des tests ».
31/05/2022 139
• Le tableau de bord Jenkins

affiche le statut de la
dernière construction du
projet ainsi que le niveau
de stabilité des dernières
constructions.
• Le tableau de bord Jenkins
fournit un raccourci pour
lancer la construction d’un
projet.
31/05/2022 140
Labs
Création d’un JOB MAVEN

Lancement automatique de Job 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
31/05/2022 142
Builds réguliers
• Il est possible de lancer la configuration du build afin d’automatiser le

lancement du build chaque minute :
31/05/2022 143
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»
• Créer et configurer le webhook dans l’outil de gestion de versionning
github:
– Passer dans le menu “Settings” de GitHub repository,
– sélectionner Webhooks
– puis clicker sur le bouton Add webhook.
31/05/2022 144
31/05/2022 145
• La Configuration de Github se fait de cette manière :

– Payload URL: Ajoutez votre nom d'hôte Jenkin (assurez-vous que le nom d'hôte
est accessible par le GitHub sinon utilisez NgRok) puis concaténer /github-
webhook/. Par exemple http://my-jenkin-host.com/github-webhook/
– Content-type: sélectionnez un type d'application/JSON
– Which events would you like to trigger this webhook? sélectionnez "Juste
l'événement push", cela déclenchera ce webhook lorsque quelqu'un poussera un
changement dans le référentiel.
– Active: cela signifie que le statut du webhook est actif et fournira les détails de
l'événement lorsque ce hook est déclenché.
31/05/2022 146
31/05/2022 147
31/05/2022 148
Labs
Création d’un JOB MAVEN Lancé automatiquement suite à un

commit
Qu’est ce qu’un Pipeline ?
• Analysez et expliquez l’arborescence suivante
31/05/2022 150
• Analysez et expliquez le contenu du Pipeline suivant
31/05/2022 151
• Analysez et expliquez le contenu du Pipeline suivant
31/05/2022 152
Exemple de pipeline
pipeline {
agent any
stages {
stage('Hello') {
steps { echo 'Hello World' }
}
stage('Java Version') {
steps { bat 'cmd /c java -version' }
}
}
}
31/05/2022 153
Labs
Tester un Pipeline Jenkins

Application
• Lisez attentivement le pipeline suivant :

pipeline {
agent any
tools{ jdk 'jdk8’ }
environment { JAVA_HOME = 'C:\\Program Files\\Java\\jdk1.8.0_281' }
stages {
stage ('Compile Stage') {
steps {
withMaven(maven : 'apache-maven-3.6.1') {
bat 'mvn clean compile'
}
31/05/2022 155
}
Application
stage ('Testing Stage') {

steps {
bat 'mvn test'
} }}
stage ('Install Stage') {
steps {
bat 'mvn install'
} } } }}
Penser à utiliser le plugin Pipeline maven intégration
31/05/2022 156
Application
1. Dites ce que permet ce pipeline de faire

2. Implémenter ce pipeline sur jenkins (il faut installer et utiliser le plugin
Pipeline maven intégration)
31/05/2022 157
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.
• L’installation de Jenkins consiste plus précisément à l’installation du

nœud ‘master’ de Jenkins qui est installé.
31/05/2022 158
BONNE PRATIQUE
• Pensez toujours à exécuter les futurs Jobs Jenkins sur des Agents
(nœuds Agents) afin de soulager le master qui est déjà très occupé à
gérer l’interface Jenkins.
31/05/2022 159
Utilité des distributions de traitements
• Cela peut
particulièrement
être utile pour
différentier
différents
environnements :
dev , Tes, recette,
préprod, prod
31/05/2022 160
Préparer un nœud Jenkins - SSH
• Créer une Machine virtuelle ubuntu (virtualbox)

• INFO : carte réseau configurée en ‘Pont’ (et non en NAT comme par défaut) pour que le host et la VM se voient.
• Valider l’installation d’un client et serveur SSH sur l’agent

– ssh
– ssh localhost
– sudo apt-get install openssh-server
– ssh localhost
31/05/2022 161
Préparer un nœud Jenkins - SSH
• Valider la communication entre l’hôte et l’agent
via SSH
– Par exemple si le host est sous windows , avec
putty.exe valider connexion ssh
• Installer Jdk8 sur l’agent

– sudo add-apt-repository ppa:webupd8team/java
– sudo apt-get update
– sudo apt-get install oracle-java8-installer
• A partir de Jenkins , ajouter un Agent

31/05/2022 162
Ajouter un agent
31/05/2022 163
Ajouter un agent
31/05/2022 164
Ajouter un agent : Explication de la configuration
1. Nom : nom de l’agent
2. Nombre d’exécutors (Ex : 2) : Nombre de job en parallèle que l’agent
peut exécuter.
3. Remote root directory : répertoire de l’agent dans lequel seront stockés
les fichiers de Jenkins (Jobs / workspace) (existant avec les privilèges nécessaires)
4. Etiquette (Label) : utilisé pour grouper un certain nombre d’agents dans
un nom logique. Tous les agents qui auront ce label sont susceptible
d’être sollicité pour exécuter un job affecté au nom du label
(typiquement ds un pipeline label ‘ubuntu’
Exemple : vous avez plusieurs agents ubuntu et vous souhaitez qu’un
job soit exécuté sous ubuntu. Vous pouvez configurer tous vos agents
ubuntu avec le label/etiquette ‘ubuntu’
31/05/2022 165
Ajouter un agent : Explication de la configuration
1. Usage : quand utiliser cet agent ? dès que possible ou seulement lorsque le
label ‘ubuntu’ est sollicité ?
2. Méthode de lancement : SSH
3. Host : ip de l’agent
4. Crédential : login/pwd du compte système de l’agent
5. Host key Verification Strategy : choisir ‘Manualy trusted key verification
strategy’
6. Ne pas cocher ‘Require manual verification of initial connection’
7. Disponibilité : par défaut ‘Keep this agent online as much as possible’
8. Propriétés du noeud : préférence d’outils de l’agent. Laisser par défaut.
31/05/2022 166
Lancer l’agent
• Sélectionner l’agent et cliquer sur ‘Launch agent’ . Ceci va déclencher

une communication SSH du maitre vers l’agent.
• et plus bas dans les logs :
31/05/2022 167
Affichage des nœuds
31/05/2022 168
Créer un job et l’exécuter dans l’agent.
• Créer un nouveau Job (freestyle) en imposant qu’il soit exécuté sur

l’Agent
31/05/2022 169

l’Agent
31/05/2022 170

l’Agent
31/05/2022 171
Labs
TP4_JENKINS Pipeline Job

Sommaire

31/05/2022 173
VIRTUALISATION D’ENVIRONNEMENT : DOCKER
DOCKER
• Agenda
– Présentation du Docker
– Travailler avec des conteneurs docker
– Travailler avec des images docker
31/05/2022 175
Présentation de Docker
31/05/2022 176
Qu'est-ce la virtualisation ?
• Ensemble de techniques et d’outils permettant de :

– faire tourner plusieurs systèmes d’exploitation sur un serveur
– Partager des ressources
• En respectant deux principes fondamentaux :
– Le cloisonnement : chaque système d’exploitation a un fonctionnement
indépendant sans aucune interférence mutuelle
– La transparence : le fonctionnement en mode virtualisé ne modifie pas le
fonctionnement du système ni des applications
31/05/2022 177
Utilité de la virtualisation ?
• Chaque application a ses propres besoins de dépendances.

– Une application java nécessite une JDK installée,
– Une application nodejs nécessite la plateforme nodejs installée et ainsi de suite.
• Les langages de programmation (java, nodejs et python) ont tous de
nombreuses versions: quelle version faut-il vraiment installer pour une
application
• Une simple application web écoute sur le port tcp 80 et peut avoir besoin à
des ressources locales sur la machine: une instance de la même application
web se heurterait au port tcp
• La réponse à toutes ces questions concerne les machines virtuelles et les
conteneurs.
31/05/2022 178
Utilité de la virtualisation ?
• Le développeur d’applications peut exporter l’application et toutes ses

dépendances installées dans une machine virtuelle ou un conteneur
• La machine ou le conteneur fournit un environnement adéquat pour
exécuter l’application sur le serveur
Nous pouvons exécuter plusieurs instances de l’application sur le

même serveur sans entrer en conflit d’adresses ni de ressources.
31/05/2022 179
Machines virtuelles vs Docker
Rest API
CLI Dockerfile
Containers
31/05/2022 180
Machines virtuelles
• Une machine virtuelle est un ensemble de systèmes d’exploitation qui

s’exécutent les uns sur les autres en utilisant un logiciel appelé
hyperviseur (vmware, oracle virtual box et ms hyper-v)
• L’hyperviseur simule le matériel tel que la mémoire et le cpu pour la
machine virtuelle
• On peut exécuter de nombreuses instances de machines virtuelles sur
une seule machine physique
31/05/2022 181
Hyperviseur vs Docker
31/05/2022 182
Docker : Présentation
• Docker est un projet open-source qui automatise le déploiement

d'applications à l'intérieur de conteneurs de logiciels en fournissant une
couche supplémentaire d'abstraction et d'automatisation de la
virtualisation au niveau du système d'exploitation
• Pris en charge par plusieurs plates-formes cloud, notamment Amazon

EC2, Google Compute Engine et Rackspace
31/05/2022 183
Editions Docker : CE et EE
31/05/2022 184
Version de Docker CE et EE
31/05/2022 185
Docker : un LXC augmenté
Définition de LXC :
• LXC est un ensemble d'outils en espace utilisateur permettant de
contrôler les LinuX Containers, un mécanisme léger de système virtuel.
• LXC implémente des systèmes virtuels complets en partant de chroot,

en ajoutant des mécanismes de gestion des ressources et d'isolation à
l'infrastructure de gestion de processus existante de Linux
• Les LXC implémentent la gestion de ressources et leurs isolation via

l’appel système clone et newinstance
31/05/2022 186
Docker : un LXC augmenté
• L'idée consiste à utiliser LXC comme base, puis à ajouter des capacités
de niveau supérieur
• Docker autorise la portabilité entre machines (qui exécutent aussi
Docker) et permet ainsi à une application et à ses composants d'exister
en tant qu'objet mobile unique.
• Avec LXC, déplacer une application sur une autre machine peut
introduire des différences susceptibles d'empêcher le conteneur de
l'application de s'exécuter.
31/05/2022 187
Architecture du docker
31/05/2022 188
Terminologie Docker
• Architecture Client/Serveur :
– Serveur = moteur ou daemon,
– Client = docker CLI
• Le client Docker communique avec le Docker daemon pour construire et gérer les conteneurs
• Le client Docker et le daemon Docker peuvent tourner sur la même machine, comme sur des
machines différentes
– Api REST qui permet de communiquer avec le daemon
• Docker File : C’est un fichier contenant l’ensemble des
commandes pour construire une image. Ce fichier
descriptif permet de construire automatiquement des
images.
31/05/2022 189
Terminologie Docker
• Image : Ensemble des couches

• Conteneur : Elément manipulable et accessible en écriture
• Registre : Une bibliothèque où les images sont stockées et peuvent être
extraites pour générer des conteneurs afin d’exécuter les services ou les
applications web
• Docker compose : fichier texte (yaml) de description d’un ensemble de
conteneurs
• Docker machine : outil de déploiement des hôtes docker sur différentes
plateformes (mac, windows) : (https://docs.docker.com/machine/overview/)
• Orchestrateur : gère un pool de ressources serveurs ( swarm, kubernetes,
mesos, rancher…)
31/05/2022 190
Docker : Architecture
31/05/2022 191
Docker : Architecture
31/05/2022 192
Docker : Images
• Les images sont un modèle binaire en

lecture seule utilisé pour créer des
conteneurs (Une image est une
représentation statique de
l’application ou du service, de sa
configuration et de ses dépendances).
31/05/2022 193
Docker : Images
• Une image contient l’application ou le service, sa configuration et de ses

dépendances
• L’image contient également des métadonnées décrivant les capacités et les

besoins du conteneur.
• Les images sont utilisées pour stocker, déployer et exécuter des applications.
• Utilisé pour générer des conteneurs
31/05/2022 194
Docker : Container
• Un conteneur est une instance active (started) ou inactive (stopped) d’une

image
• Un conteneur enveloppe l’application d’un logiciel dans une boîte invisible
avec tout ce dont il a besoin pour s’exécuter (système d'exploitation, code de
l'application, runtime, outils système et les librairies).
• Les conteneurs sont légers, portables et permettent aux développeurs de
créer, déployer et exécuter efficacement des applications distribuées.
• Les conteneurs permettent à une application d’être empaquetée et déplacée
facilement, augmentant ainsi la simplicité d'une infrastructure.
31/05/2022 195
Docker : Registre (Registry)
• Les registres Docker sont des services qui fournissent des emplacements
à partir desquels vous pouvez stocker et télécharger des images.
31/05/2022 196
Labs
Installation Docker CE
31/05/2022 197
Travailler avec des conteneurs
docker
31/05/2022 198
Rechercher une image
• Les images sont disponibles dans un registre Docker privé ou publique
# docker search motif
# docker search --filter is-official=true --filter stars=3 fedora
# docker search --help
31/05/2022 199
Télécharger une image
# docker pull NAME[:TAG]
# docker pull image:tag Télécharger un version spécifique d’une image
# docker pull --all-tags centos Télécharger toutes les versions d’une image
# docker pull --help

31/05/2022 200
Lister des images
• Les images peuvent être extraites depuis un registre, importées via la

commande docker ou créées via des Dockerfile.
# docker images
# docker images --filter "name=nginx"
# docker images --help

31/05/2022 201
Démarrer un conteneur
# docker run [ OPTIONS ] IMAGE[:TAG] [COMMAND] [ARG...]
• -i démarre le conteneur en mode interactif

• -t alloue un pseudo-tty et l'attache à l'entrée standard
• -d : démarrer le conteneur en arrière-plan
• --rm : Supprimer le conteneur une fois terminé
• --read-only : interdit la modification sur le système de fichiers racine
# ID=$(docker create -t -i centos bash)
# docker start -a -i $ID
31/05/2022 202
Lister des conteneurs
• Nous pouvons lister les conteneurs en cours d'exécution et arrêtés.

# docker ps [ OPTIONS ]
# docker ps –a Lister les conteneurs en cours d'exécution et arrêté
# docker ps –aq Renvoyer uniquement les ID de conteneur de tous les

conteneurs
# docker ps --help
31/05/2022 203
Consulter les logs des conteneurs
• Si le conteneur émet des journaux ou une sortie sur STDOUT/STDERR,

nous pouvons les obtenir sans nous connecter au conteneur.
# docker logs [-f|--follow[=false]][-t|--timestamps[=false]] CONTENEUR
Lister les conteneurs en cours d'exécution et arrêté
# docker logs –t -f
# docker logs --help

31/05/2022 204
Arrêter un conteneur
# docker stop [-t|--time[=10]] CONTAINER [CONTAINER...]
# docker stop $(docker ps -q)
Arrêter les conteneurs

en cours d'exécution
# docker stop --help
31/05/2022 205
Supprimer un conteneur
• Nous pouvons supprimer un conteneur de manière permanente, mais

avant cela, nous devons arrêter le conteneur ou utiliser l'option forcer.
# docker rm [ OPTIONS ] CONTAINER [CONTAINER...]
rm
-f : Forcer la suppression
# docker rm –help
31/05/2022 206
Définition de la stratégie de redémarrage
sur un conteneur
# docker run --restart=POLICY [ OPTIONS ] IMAGE[:TAG] [COMMAND] [ARG...]
Vous avez le choix entre trois stratégies de redémarrage:

– no: ne pas démarrer le conteneur s'il meurt
– on-failure: redémarrer le conteneur s'il échoue avec un code de sortie
différent de zéro Lister les conteneurs en cours d'exécution et arrêté
– always: redémarrer toujours le conteneur sans se soucier du code retour
# docker run --restart=on-failure:3 -d -i -t fedora /bin/bash
ne redémarrer le conteneur que trois fois, en cas d'échec.

31/05/2022 207
Exposer des ports
Exposez un port ou une plage de ports
# docker run --expose=PORT [ OPTIONS ] IMAGE[:TAG] [COMMAND] [ARG...]
31/05/2022 208
Exécuter un nouveau processus dans un
conteneur en cours d'exécution
• L'option exec permet d’injecter un nouveau processus dans un
conteneur en cours d'exécution.
# docker exec [-d|--detach[=false]] [--help] [-i|--interactive[=false]]
[-t|--tty[=false]] CONTAINER COMMAND [ARG...]
# docker exec --help
31/05/2022 209
Examiner un container
Examiner les processus en cours d' exécution à l'intérieur d’un container :

# docker top [OPTIONS] NAME|ID
Examiner les statistiques d’utilisation (cpu, ram, net, bloc i/o...) pour un ou
plusieurs containers en cours de fonctionnement :
# docker stats [OPTIONS] [NAME|ID]
31/05/2022 210
Examiner un container
Lors du débogage, de l'automatisation, etc., nous aurons besoin des détails de

configuration du conteneur. Docker fournit la commande inspect pour les
obtenir facilement utilisant le format Go :
# docker inspect [OPTIONS] NAME|ID [NAME|ID...]
# docker inspect --format='{{.NetworkSettings.IPAddress}}' $ID
# docker inspect --help
31/05/2022 211
Labs
Manipulation des conteneurs avec le CLI
31/05/2022 212
Travailler avec des images docker
31/05/2022 213
Créer un compte avec Docker Hub
• Il s'agit d'un registre public sur lequel vous pouvez héberger des images à la fois
publiques et privées, les partager et collaborer avec d'autres.
• Il est intégré à GitHub, Bitbucket et peut déclencher des builds automatisés.
• Un référentiel peut contenir différentes versions d'une image.
• Par défaut, un référentiel privé + plusieurs référentiels publics
https://hub.docker.com/
# docker login
31/05/2022 214
Créer une image à partir du conteneur
(1/2)
Il existe plusieurs façons de créer des images, l'une consiste à valider
manuellement des couches et l'autre à utiliser Dockerfiles.
# docker commit -a|--author[=""] -m|--message[=""] CONTAINER [REPOSITORY[:TAG]]
# docker commit -a "JEMAL" -m "Centos Avec HTTPD" c83ff3f4c9e2 jemal/centos:httpd
31/05/2022 215
Créer une image à partir du conteneur
(2/2)
Pour rechercher des fichiers modifiés depuis le démarrage du conteneur:
# docker diff Conteneur
Liste des préfixes avant chaque entrée de la sortie:

• A: C'est pour dire qu’un fichier / répertoire
a été ajouté
• C: C'est pour dire qu’un fichier / répertoire
a été modifié
• D: C'est pour dire qu’un fichier / répertoire
a été supprimé
31/05/2022 216
Publication d'une image dans le registre
# docker push NAME[:TAG] Public (Docker hub)
# docker push [REGISTRYHOST/][USERNAME/]NAME[:TAG] Privé
# docker push --help
31/05/2022 2 217
Historique d'une image
# docker history [ OPTIONS ] IMAGE
# docker inspect --format='{{.Comment}}’ jemal/centos:httpd
# docker history --help
31/05/2022 218
Supprimer une image
# docker rmi [ OPTIONS ] IMAGE [IMAGE...]
# docker stop `docker ps -q` Arrêter tous les conteneurs
# docker rm `docker ps -a -q` Supprimer tous les conteneurs
# docker rmi `docker images -q` Supprimer toutes les images
31/05/2022 219
Exporter/Importer une image
# docker save [-o|--output=""] IMAGE [:TAG] Image
# docker export CONTAINER > containerXYZ.tar Conteneur
# docker import URL|- [REPOSITORY[:TAG]]
31/05/2022 220
Création d'images à l'aide de Dockerfile
• Les images Docker peuvent être créées de 2 manières différentes:

– En travaillant sur un conteneur, puis en le sauvegardant en exécutant la
commande docker commit
– En modifiant un fichier Docker dans le système de fichiers hôte et en exécutant la
commande docker build
31/05/2022 221
Création d'images à l'aide de Dockerfile
• Exemple :
FROM centos:latest
MAINTAINER JEMAL
CMD date
# docker build .
L’option -t spécifie le nom du référentiel

ou de la balise pour l'image
31/05/2022 222
Le format du Dockerfile
• FROM : La première instruction de tout Dockerfile, qui définit l'image de

base pour les instructions suivantes. [OBLIGATOIRE]
FROM <images>:<tag>
FROM ubuntu Par défaut, le tag est latest
FROM devops/ubuntu-ssh:16.04
• LABEL : En utilisant l'étiquette, vous pouvez organiser les images de
manière appropriée. Ceci est utile pour définir l'adresse du responsable,
le nom du fournisseur, la version de l'image, la date de sortie, etc.
LABEL maintainer= “jemal@yahoo.fr" LABEL LABEL maintainer= "jemal@yahoo.fr" \
vendor= “FR" vendor= "FR" \
LABEL com.example.version="0.0.1" com.example.version="0.0.1"
46
31/05/2022 223
• MAINTAINER: définit l'auteur de l'image générée

MAINTAINER <name>
• RUN : exécuter n'importe quelle commande sur l'image pendant la
construction
RUN <command> <param1> ... <pamamN> Comme shell (sh -c)
RUN ["executable", "param1",...,"paramN" ] Comme exécutable
RUN apt-get update
RUN apt-get install -y apache2 automake build-essential
curl
RUN apt-get update && apt-get install -y \ automake \
build-essential \ curl \
31/05/2022 224
• CMD : utilisé pour exécuter le service ou le logiciel contenu par votre

image, ainsi que les éventuels arguments lors du lancement du
conteneur.
CMD ["executable", "param1",...,"paramN" ] Comme exécutable
CMD <command> <param1> ... <pamamN> Comme shell (sh -c)
CMD ["param1", ... , "paramN"] fournir des arguments à ENTRYPOINT.
• Exemple: pour démarrer le service Apache lors du lancement du

conteneur
CMD ["apache2ctl", "-D", "FOREGROUND"]
31/05/2022 225
• ENTRYPOINT : Spécifier une commande ou un exécutable comme point

d’entrée du conteneur
ENTRYPOINT ["executable", "param1",...,"paramN"] Comme exécutable
ENTRYPOINT <command> <param1> ... <pamamN> Comme shell (sh -c)
ENTRYPOINT import.sh
• WORKDIR : définit le répertoire de travail pour les instructions

RUN, CMD et ENTRYPOINT
WORKDIR <PATH>
WORKDIR /opt
31/05/2022 226
• ADD : copier des fichiers et des répertoires du système hôte vers l'image
pendant la construction.
ADD <src> <dest>
ADD ["<src>"... "<dest>"] Pour le chemin contenant des espaces
ADD run-apache.sh /run-apache.sh
• COPY : Similaire à ADD, copier les fichiers de la source vers la

destination
COPY ["<src>"... "<dest>"]
COPY html/* /var/www/html/

COPY *.conf /etc/apache2/sites-available/
31/05/2022 227
• VOLUME: créer un point de montage avec le nom donné et le marquera

comme point de montage du volume externe
VOLUME ["/data"]
VOLUME /data
• EXPOSE : exposer les ports réseau du conteneur sur lesquels il

écoutera au moment de l'exécution
EXPOSE <port> [<port> ... ]
EXPOSE 80
EXPOSE 443
31/05/2022 228
• ENV : Définir des variables d'environnement pour un service spécifique

du conteneur.
ENV <key> <value>
ENV PATH=$PATH:/usr/local/pgsql/bin/
ENV CONT_IMG_VER=v1.0.0
• USER : Définir le nom d'utilisateur (ou UID) à utiliser lors de

l'exécution de l'image et pour toutes les instructions RUN, CMD et
ENTRYPOINT
USER <username>/<UID>
USER patrick
31/05/2022 229
Exemples du Dockerfile (1/2)
• Affichage d’un FROM ubuntu:14.04

message en entrée ENTRYPOINT ["/bin/echo"]
FROM centos:7
• Empaquetage du Maintainer jmlhmd@gmail.com
serveur Apache RUN yum update -y && yum clean all
dans un conteneur RUN yum install httpd -y && yum clean all
RUN echo "Ceci est un exemple pour créer une image basé \
sur Centos avec Le serveur Web pré-installé" \
> /var/www/html/index.html
ENTRYPOINT apachectl "-DFOREGROUND"
31/05/2022 230
Exemples du Dockerfile (2/2)
• Empaquetage
d'une application FROM ubuntu:14.04
Flask dans un
RUN apt-get update
conteneur RUN apt-get install -y python
RUN apt-get install -y python-pip
RUN apt-get clean all
RUN pip install flask
ADD hello.py /tmp/hello.py EXPOSE 5000
CMD ["python","/tmp/hello.py"]
31/05/2022 231
Labs
Manipulation des Dockerfiles
31/05/2022 232
Sommaire

31/05/2022 233
GESTION DES LIVRABLES
31/05/2022 234
Gestion des livrables
• Agenda
– Notion de dépôt d'artefacts
– Stratégie de mise à disposition du résultat construit
– Le gestionnaire de dépôt d'artefacts Archiva
31/05/2022 235
Notion de dépôt d'artefacts
• Un dépôt d’artefacts, dit également repository, est une collection

d'artefacts logiciels binaires et de métadonnées stockés dans une
structure de répertoire définie, qui est utilisée par des clients tels que
Maven pour récupérer des binaires.
• Dans le cas des dépôts d’artefacts Maven, le type principal d'artefact
binaire est un fichier JAR.
• Il n'y a pas de limite aux types d'artefacts pouvant être stockés dans un
dépôt Maven qui peut stocker également:
– Des archives de documentation.
– Des archives de codes sources, etc.
31/05/2022 236
Notion de dépôt d'artefacts
• Un dépôt fournit une plate-forme pour le stockage, la récupération et la

gestion des artefacts et des métadonnées du logiciel binaire.
• Dans le paradigme Maven, chaque artefact logiciel est décrit par un
document XML (Project Object Model ou POM).
• Le POM contient des informations qui décrivent un artefact logiciel et
répertorient ses dépendances, i.e. les artefacts logiciels binaires dont
dépend un composant donné pour une compilation ou une exécution
réussie.
• Lorsque Maven télécharge une dépendance à partir d'un dépôt
d’artefacts, il télécharge également le POM de cette dépendance.
31/05/2022 237
Stratégie de mise à disposition du résultat :
Dépôts de Release et dépôts de Snapshot
• Les dépôts de Release sont destinés aux artefacts de release stables.
• Les dépôts de Snapshot sont des dépôts fréquemment mis à jour,
utilisés pour le stockage des artefacts logiciels provenant de projets en
cours de développement.
• Les dépôts sont généralement segmentés en release ou snapshot
servant différents consommateurs et appliquant des normes et des
procédures différentes pour le déploiement d'artefacts.
• Un dépôt de release est considéré comme un dépôt de production et un
dépôt de snapshot est considéré comme un dépôt de développement
ou de test.
31/05/2022 238
Stratégie de mise à disposition du résultat :
Dépôts de Release et dépôts de Snapshot
• Les artefacts snapshot sont des artefacts générés lors du

développement d'un projet logiciel.
• Les artefacts snapshot peuvent être déployés et modifiés fréquemment
sans tenir compte des problèmes de stabilité et de répétabilité.
31/05/2022 239
Les gestionnaires de dépôt d'artefacts
• Un gestionnaire de dépôt d'artefacts est:

– Un proxy pour les dépôts distants qui met en cache les artefacts, en économisant
à la fois la bande passante et le temps requis pour récupérer un artefact logiciel à
partir d'un dépôt distant.
– Un hôte pour les artefacts internes fournissant à une organisation un
environnement de déploiement pour les artefacts logiciels.
• Un gestionnaire de dépôt d'artefacts est capable de gérer les artefacts
logiciels binaires.
• Un gestionnaire de dépôt d'artefacts peut rechercher des artefacts
logiciels, vérifier des opérations de développement et de publication
31/05/2022 240
Les gestionnaires de dépôt d'artefacts :
Apache archiva
• Apache Archiva est un logiciel de gestion de dépôt d’artefacts qui
permet de gérer des dépôts d'artefacts personnels ou internes à une
organisation.
• Archiva permet de gérer des dépôts d’artefacts de type:
– Internal: permet de gérer les artefacts de release ayant une version fixe. Ces
versions sont testées, validées et ne sont plus en cours de développement.
– Snapshot: permet de gérer les artefacts de snapshot qui sont encore en cours de
développement. Le numéro de version de ces artefacts porte le suffixe
SNAPSHOT.
31/05/2022 241
Les gestionnaires de dépôt d'artefacts :
Apache archiva
31/05/2022 242
Labs
Mise en place d’archiva

Sommaire

31/05/2022 244
L’AUTOMATISATION DES TESTS
31/05/2022 245
L’automatisation des tests
• Agenda
– Les différents types de tests
– Les outils de test
– Automatisation des tests
– Les environnements de test
– Configuration des rapports de test dans Jenkins
– Consultation des rapports de test dans Jenkins
31/05/2022 246
Les différents types de tests : Les tests
unitaires
• Un test unitaire est un procédé permettant de s'assurer du bon
fonctionnement d'une unité de programme isolée de tout autre facteur.
• Il s’agit de vérifier, en fonction de certaines données fournies en entrée
d’un module de code que les données qui en sortent ou les actions qui
en découlent sont conformes aux spécifications du module.
• Les tests unitaires ont deux objectifs :
– Couverture de code : tester chaque ligne de code du programme à tester
(boucle, décision, appel de méthode, etc.).
31/05/2022 247
unitaires
– Couverture de données: tester la réponse du programme avec des données
valides ou invalides, peu ou trop de données, etc.
• Les tests unitaires sont généralement écrits par les développeurs eux-
mêmes pour la validation de leurs codes.
• Les entrées du test sont définies à partir de l’analyse du code source du
programme.
• Les tests unitaires sont des tests en boite blanche.
31/05/2022 248
d’intégration
• Intégration: c'est le fait d'assembler plusieurs composants logiciels
élémentaires pour réaliser un composant de plus haut niveau.
• intégration continue: consiste à rendre automatique l'intégration des
différents composants d'un système dès que ces composants sont
modifiés, pour faire en sorte que les effets produits par ces
modifications soient rapidement mesurables.
• Les tests d'intégration visent à s'assurer du bon fonctionnement de la
mise en œuvre conjointe de plusieurs unités de programme, testées
unitairement au préalable.
31/05/2022 249
d’intégration
• Les tests d'intégration visent à s'assurer aussi que le produit est
compatible avec l’environnement d’exécution du logiciel.
• Les tests d'intégration sont des tests en boite blanche.
31/05/2022 250
fonctionnels
• Les tests fonctionnels ont pour objectif de valider la conformité des
comportements du logiciel par rapport aux spécifications.
• Ils sont basés sur les spécifications, qui déterminent le comportement
attendu.
• Ils sont conduits dans un contexte le plus proche possible de l’utilisation
réelle du logiciel.
• Ils permettent de réaliser les principales tâches pour lesquelles a été
conçu et développé le logiciel.
• Ils permettent de détecter les erreurs de conception afin de les corriger
par la suite.
31/05/2022 251
fonctionnels
• Depuis les spécifications nous pouvons définir les données du test.
• Depuis les spécifications nous pouvons prédire les résultats de test.
• En passant ces données de test dans le programme à tester, nous
pouvons comparer les résultats d’exécution avec les résultats prédis.
• Les tests fonctionnels sont des tests en boite noir.
31/05/2022 252
Les différents types de tests : Les tests de
charge
• Les tests de charge ont pour objectif de mesurer les réponses d’un
système soumis à un volume d’utilisateurs accru pour en vérifier la
capacité à soutenir le trafic attendu. Ils se déclinent dans 4 catégories.
• Les tests de charge « classiques » qui servent en général à vérifier que le
système peut tenir des temps de réponse cibles pour un volume
d’utilisateurs donné.
• Les tests de résistance au stress qui s’intéressent au comportement du
système face à des conditions extrêmes après avoir atteint une exigence
cible, telle que définie par le test de charge.
31/05/2022 253
Les différents types de tests : Les tests de
charge
• Les tests de capacité. Il s’agit d’un type spécifique de test de résistance
au stress, qui aide à identifier le nombre maximal d’utilisateurs gérable
par le système.
• Les tests d’endurance qui examine le comportement du système lors
d’une exécution sur la durée (par exemple, sur plusieurs jours) après
avoir atteint ses exigences cibles, telles que définies par le test de
charge.
• les résultats d’un test de charge sont fluctuants et ouverts à
interprétation.
31/05/2022 254
Les différents types de tests : Les outils de
test
31/05/2022 255
L’automatisation des tests : Le test manuel
• Assuré par un testeur qui :

– Conçoit manuellement des cas de tests à partir d’une spécification informelle.
– Entre les données de tests.
– Lance les tests.
– Observe les résultats et les compare avec les résultats attendus.
• Un processus fastidieux avec possibilité d'erreur humaine.
• Un processus long et répétitif.
• Ingérable pour les grosses applications.
• Génère un coût important.
31/05/2022 256
L’automatisation des tests : Le test
automatisé
• Assuré par des outils qui déchargent le testeur de:
– Génération des cas de tests.
– Du lancement des tests.
– De l'enregistrement des résultats.
• Un gain en temps et un gain en productivité.
31/05/2022 257
L’automatisation des tests : Les bénéfices
de l’automatisation
• Meilleure couverture de l’application :
– Exécution de plus de tests automatiques que manuels en un même intervalle de
temps.
– Minimiser les problèmes de non régression. Focalisation des tests manuels sur
les nouvelles fonctionnalités.
• Meilleure fiabilité de l’application :
– Meilleure couverture.
– Stabilité du produit.
– Résultat rigoureux.
– Pas d’intervention humaine lors de l’exécution du test.
31/05/2022 258
L’automatisation des tests : Les bénéfices
de l’automatisation
• Diminution des coûts du développement:
– Les défauts découverts plus précocement coûtent moins cher à corriger.
• Gain de temps:
– Exécution rapide.
– Détection rapide des problèmes.
– Concentration sur l’analyse du problème.
– Accélérer la mise en production des évolutions dans des situations très
compétitives.
• Réduction du temps consacré au test :
– Le temps d'exécution en automatique est généralement plus court.
31/05/2022 259
L’automatisation des tests : Les limites de
l’automatisation
• Coût de la mise en place important :
– La mise en place est assez coûteuse.
– Il est plus facile d’écrire un test manuel qu’un test automatique.
– Le ROI est assuré avec la répétition des tests.
• Plus adaptée à des logiciels de grosse taille avec une activité de tests
répétitive.
• Contrainte sur l’écriture du test :
– Les données de test doivent être établies le plus rigoureusement possible.
– Les coûts de maintenance sont vite élevés si les scénarios de tests changent
souvent.
31/05/2022 260
L’automatisation des tests : Les limites de
l’automatisation
 Essayer de couvrir le code source à 100% peut se révéler inefficace et très coûteux.
• La mise en place de l’automatisation nécessite :
– Une expertise technique en la matière.
– Des outils, soumis à un coût de licence pour certains.
– Du temps, de l’effort et du budget.
• L’automatisation n’est pas une baguette magique qui permettra de
produire un logiciel 0 anomalie !
• “Testing can only reveal the presence of errors but never their absence”
– Dijkstra (Notes on Structured Programming, 1972).
31/05/2022 261
L’automatisation des tests : Choisir les
tests à automatiser
• Il faut trouver le bon équilibre entre :
– Couverture de test.
– Granularité des tests.
– La maintenabilité des tests.
• La mise en place des tests automatisés doit être la moins compliquée et
la plus performante possible.
31/05/2022 262
• Les tests répétitifs :
– Un critère majeur pour décider si un test doit être automatisé.
– Le coût de la mise en place de l’automatisation est amorti sur le nombre
d’exécution du test.
– Convient pour des projets où des tests de non régression sont joués d’une
manière récurrente.
• Les tests fastidieux qui réclament une attention soutenue de l'opérateur.
• Les tests qui nécessitent une instrumentation complexe.
• Les tests de longue durée, de stabilité et de fiabilité.
• Les tests de contrôle des temps de réponse.
31/05/2022 263
• Les tests qui ne sont pas possibles autrement.
• Ne convient pas pour des projets :
– De petite taille.
– De courte durée.
– Des changements mineurs.
31/05/2022 264
Les environnements de test :
Environnement d’intégration
• Environnement dans lequel les différents composants du logiciel sont
mis en relation entre eux et également avec les autres logiciels en
amont et en aval pour un test complet de la solution globale.
• Les tests effectués dans cet environnement sont généralement des tests
de communication entre les différents composants de la solution.
31/05/2022 265
Les environnements de test :
Environnement de recette
• La recette est une phase de développement des projets, visant à assurer
formellement que le produit est conforme aux spécifications techniques
et fonctionnelles.
• La recette technique permet de contrôler les caractéristiques
techniques du produit livré.
• La recette fonctionnelle a pour but la validation des fonctionnalités
exprimées dans le cahier des charges et détaillées dans les
spécifications fonctionnelles.
• L’environnement de recette est l'environnement qui permet de dérouler
les tests de validation technique et fonctionnelle du produit.
31/05/2022 266
Les environnements de test : Environnement
de test d’acceptation utilisateur
• Les tests d'acceptation utilisateur (UAT) constituent la dernière phase du
processus de test logiciel.
• Au cours de l'UAT, les utilisateurs finaux du produit testent le logiciel
pour s'assurer qu'il puisse gérer les tâches requises dans des scénarios
réels, selon les spécifications.
• L’UAT est l'une des procédures qui doit avoir lieu avant que le logiciel
nouvellement développé soit déployé en production.
• L'UAT est également connu sous le nom de test bêta, test d'application
ou test d'utilisateur final.
31/05/2022 267
Les environnements de test : Environnement
de test d’acceptation utilisateur
• L’UAT implique directement les utilisateurs prévus du logiciel. L'UAT peut
être mis en œuvre en rendant un logiciel disponible pour un essai de
bêta gratuit sur Internet ou par le biais d'une équipe de test interne
composée d'utilisateurs de logiciels réels.
• L'UAT est important car il permet de démontrer que le logiciel
fonctionne de manière adaptée aux circonstances et à l'utilisation
réelles.
• L’environnement UAT est très proche de la production.
31/05/2022 268
Configuration des rapports de tests
• L’exécution des tests est une tâche incluse dans la construction du

projet.
• Pour la construction des projets Maven, il faut paramétrer la
construction de sorte que le goal « test » ou « verify » soit exécuté
durant la construction.
• L’exécution des tests avec des frameworks de type JUnit génère des
rapports de résultats de tests intégrables dans Jenkins.
31/05/2022 269
• La configuration des goals Maven est proposée via la vue «Nom de Job
> Configuration » accessible depuis le tableau de bord Jenkins.
31/05/2022 270
31/05/2022 271
Consultation des rapports de tests
• Le plugin Junit de Jenkins fournit un éditeur qui consomme les rapports de

tests XML générés pendant les constructions des projets et fournit une
visualisation graphique de l’historique des résultats des tests ainsi qu'une
interface web pour afficher les rapports de tests, les échecs, les succès, etc.
• Jenkins intègre le format XML du rapport de test JUnit (qui est également
utilisé par TestNG). Si cette option est configurée, Jenkins peut fournir des
informations utiles sur les résultats des tests, tels que les tendances.
• L’installation du plugin JUnit est disponible via le gestionnaire de plugin
dans la vue « Administrer Jenkins > Gestion des plugins » dans l’onglet
Disponible.
31/05/2022 272
31/05/2022 273
31/05/2022 274
• Les résultats de l’exécution des tests unitaires sont consultables dans la

vue « Résultat des tests » accessible depuis le tableau de bord Jenkins.
31/05/2022 275
• Les résultats de l’exécution des tests unitaires sont consultables dans la

vue « Résultat des tests » accessible depuis le tableau de bord Jenkins.
31/05/2022 276
31/05/2022 277
• L’historique des résultats des tests est disponible via le menu

« Historique ».
31/05/2022 278
31/05/2022 279
Sommaire

31/05/2022 280
GESTION DE LA QUALITÉ DU CODE
31/05/2022 281
GESTION DE LA QUALITÉ DU CODE
• Agenda
– La mise en place des métriques
– Les outils d’analyse et de reporting (Checkstyle, Findbugs, PMD, tec.)
– La génération de rapports d’analyses
– La publication des résultats dans Jenkins
– Configuration de SonarQube
– La publication des résultats dans SonarQube
31/05/2022 282
La mise en place des métriques : Qualité
logicielle
• Selon Wikipedia : « La gestion de la qualité regroupe les techniques et
organisations concourant à rendre conforme à un standard la
production de biens ou de services ».
• L’ANSI définit la qualité comme « l'ensemble des attributs et
caractéristiques d'un produit ou d'un service qui portent sur sa capacité
à satisfaire des besoins donnés ».
• Dans le monde informatique en général, la qualité d’une solution
logicielle est directement liée à la qualité du code lui-même.
31/05/2022 283
La mise en place des métriques : Qualité
logicielle
• 6 indicateurs de qualité logicielle (Norme ISO 9126) :
– Fonctionnalités, la réponse aux exigences et besoins des utilisateurs.
– Utilisabilité, l’effort nécessaire pour l’appropriation de la solution.
– Fiabilité , capacité de rendre des résultats corrects en toute circonstance.
– Efficacité, le ratio entre les ressources utilisées et les résultats délivrés.
– Maintenabilité, l’effort nécessaire à la correction de la solution.
– Portabilité, la capacité à fonctionner dans différents environnements.
31/05/2022 284
La mise en place des métriques :
Facteurs & critères de qualité
– Les 6 grands thèmes identifiés dans la

norme ISO 9126 correspondent aux
facteurs de qualité.
– Chaque facteur de qualité peut être
décliné en différents critères.
31/05/2022 285
Evaluation de la Qualité
Facteur Critère Attribut
mesurable
Taille des programmes
Lisibilité du code
• L’évaluation de la qualité Facilité d’Analyse
Auto-description
consiste à définir les attributs
…
mesurables de chaque critère Expressions et aspects
de qualité identifié : Facilité de
Modification
OO
Maintenabilité Flot de contrôle
Facilité de test Complexité
31/05/2022 286
Métrologie
• L’évaluation de la qualité s’appuie sur des éléments de Métrologie
adaptés à chaque attribut mesurable.
• La Métrologie doit:
– Définir l’ensemble des caractéristiques mesurables du logiciel.
– Définir les méthodes et les outils d'évaluation.
– Evaluer le logiciel par la mise en œuvre de ces méthodes et de ces outils.
• La métrologie porte sur :
– La qualité du processus de développement.
– La qualité du service.
– La qualité intrinsèque du logiciel.
31/05/2022 287
La mise en place des métriques : Les
Métriques
• Exemple de métriques :
Facteur Critère Attribut Métrique
mesurable
Taille des programmes Nombre de lignes
de code
Lisibilité du code % de code mort
Facilité d’Analyse
Auto-description % de lignes de
commentaires
…
Respect des normes
Expressions et aspects OO Respect du modèle

Maintenabilité Facilité de Modification
en couches
Flot de contrôle
Facilité de test Complexité Complexité

cyclomatique
31/05/2022 288
La mise en place des métriques : La qualité
du code
• Un des volets impactant la qualité de la solution logicielle est la qualité
du code source composant la solution.
• La qualité du code source est évaluée sur la base de métriques associées
aux critères identifiés dans le cadre de la démarche de qualité.
• L’évaluation est régulière, les résultats de l’évaluation sont publiés, et
des actions correctives sont mises en œuvre.
31/05/2022 289
Les métriques du code Java
• L’évaluation de la qualité du code Java s’appuie sur un certain nombre
de métriques, calculées sur l’analyse statique du code source :
– La taille des éléments du projet :
• Le nombre de lignes dans un fichier source.
• Le nombre de classes dans un package.
• Le nombre de méthodes dans une classe.
• Le nombre de paramètres pour une méthode.
– La lisibilité des éléments du projet :
• Le nombre de lignes pour une méthode.
• L’organisation, l’indentation, la documentation des lignes de code.
31/05/2022 290
Les métriques du code Java
– L’architecture du projet :
• Le découpage en packages.
• Les dépendances entre packages.
• Le respect des couches logicielles.
– Le nombre et l’étendue des tests unitaires.
31/05/2022 291
Les outils d’analyse et de reporting
• Les différentes métriques identifiées peuvent êtres calculées par un

certain nombre d’outils existants:
– Checkstyle:
• Prend en charge le contrôle du respect des conventions de codage.
• Contrôle les règles de nommage, d’indentation et d’organisation des éléments du projet
(fichiers, packages, classes, …).
– PMD / CPD:
• Prend en charge le contrôle du respect de la non duplication de code.
• Permet d’assurer le niveau de factorisation adapté.
31/05/2022 292
Les outils d’analyse et de reporting
– FindBugs
• Prends en charge la détection des principaux patterns de programmation pouvant conduire à
l’apparition de bugs (anomalie, sécurité, performances, …).
– JDepend ++
• Prend en charge le contrôle des dépendances entre les packages et les classes.
• Fait ressortir les cycles et le non respect des conventions d’architecture.
– JUnit & Cobertura
• Pour jouer les tests unitaires et mesurer la couverture de ces mêmes tests unitaires.
• Permet de détecter les parties du code qui ne sont pas testées.
31/05/2022 293
La génération de rapports d’analyse
• La génération des rapports d’analyse de code est assurée par les outils
d’analyse intégrés dans Jenkins via des plugins appropriés.
• Jdepend est un plugin qui peut être installé à part
• Un plugin viens remplacer les anciens plugins des outils d’analyse de
code tel que Checkstyle, PMD, FindBugs, etc, c’est le plugin « warning
next generation »
• Il est disponible via le gestionnaire de plugins dans la vue « Administrer
Jenkins > Gestion des plugins » dans l’onglet Disponible.
31/05/2022 294
Rapports d’analyse : Plugin warning next
generation
31/05/2022 295
Rapports d’analyse Checkstyle : à partir du
Plugin warning next generation
31/05/2022 296
Rapports d’analyse PMD : à partir du
31/05/2022 297
Rapports d’analyse FindBugs : à partir du
31/05/2022 298
La génération de rapports d’analyse :
Installation du plugin JDepend
31/05/2022 299
La génération de rapports d’analyse
31/05/2022 300
Configuration de la construction
• Pour configurer la génération des rapports d’analyse du code lors de la
construction du projet, aller dans vue de la configuration du Job de la
construction « NOM_JOB > Configurer ».
• Dans la section « Configuration du build »,
– Dans la section « build », ajouter les Goals et options :
• clean install checkstyle:checkstyle pmd:pmd findbugs:findbugs
– Dans la section « Actions à la suite du build », ajouter l’action:
• Record compiler warnings and static analysis results
– Choisissez les options : PMD, Checkstyle et Findbugs
• Report Jdepend.
31/05/2022 301
31/05/2022 302
31/05/2022 303
La publication des résultats dans Jenkins
• La consultation des résultats d’analyse du code est disponible dans la

vue « NOM_JOB » accessible depuis le tableau de bord Jenkins.
31/05/2022 304
La publication des résultats dans Jenkins :
Les tendances
31/05/2022 305
Les résultats de Checkstyle
31/05/2022 306
La publication des résultats dans Jenkins : Les
résultats de PMD
31/05/2022 307
Les résultats de JDepend
31/05/2022 308
Le serveur SonarQube
• Outil open source soutenu par une forte communauté très active.
• Fournit un composant global et centralisé de gestion et contrôle de la
qualité.
• Regroupe l’ensemble des outils de contrôle qualité : Checkstyle,
PDM/CPD, FindBugs, Jdepend, Junit & Cobertura.
• Fournit une interface d’administration et de configuration centralisée.
• Permet la définition de profils qualités différents par projet.
• Permet la gestion des habilitations par utilisateurs et groupes.
31/05/2022 309
Le serveur SonarQube
• Peut être facilement étendu à l’aide de plugins additionnels.

• S’interface très facilement avec d’autres outils de développement :
Intégration continue, Outil de documentation projet / Wiki, Outils de
tests fonctionnels, …
• Directement exploitable dans l’environnement du développeur.
• Mise en œuvre très simple ne nécessitant pas une grosse infrastructure.
31/05/2022 310
LABS
Installation du serveur Sonarqube

Configuration de SonarQube :
Installation du plugin SonarQube Scanner
• Le serveur SonarQube s’intègre dans Jenkins via le plugin SonarQube

Scanner.
• L’installation du plugin SonarQube Scanner est disponible via le
gestionnaire de plugin dans la vue « Administrer Jenkins > Gestion des
plugins » dans l’onglet Disponible.
31/05/2022 312
31/05/2022 313
31/05/2022 314
Configuration de SonarQube
• La configuration du serveur SonarQube est disponible via la vue

« Configurer le système » accessible depuis « Administrer Jenkins >
Configurer le système ».
• Faites défiler jusqu'à la section de configuration SonarQube Servers,
cliquez sur « Ajouter une installation SonarQube ».
31/05/2022 315
31/05/2022 316
31/05/2022 317
Configuration du plugin SonarQube Scanner
• La configuration du plugin SonarQube Scanner est disponible via la vue

« Configuration globale des outils » accessible depuis « Administrer
Jenkins > Configuration globale des outils ».
• Faites défiler jusqu'à la section de configuration SonarQube Scanner,
cliquer sur « Ajouter SonarQube Scanner ».
31/05/2022 318
31/05/2022 319
31/05/2022 320
Configuration du Job d’analyse du code
• La configuration du Job d’analyse du code est accessible depuis le
tableau de bord Jenkins.
• Ajoutez une étape pré-build « Lancer une analyse avec SonarQube
Scanner » dans la configuration du Job d’analyse du code.
31/05/2022 321
Configuration du Job d’analyse du code
31/05/2022 322
Publication des résultats dans SonarQube
• L’exécution du Job d’analyse du code permet de publier les résultats de

l’analyse dans SonarQube.
• SonarQube est accessible depuis la vue « Nom_Job ».
31/05/2022 323
31/05/2022 324
• Le tableau de bord
31/05/2022 325
Publication des résultats dans SonarQube :
Les problèmes détectés
31/05/2022 326
Publication des résultats dans SonarQube :
Les statistiques
31/05/2022 327
LABS
Testez la configuration précédente d’intégration Jenkins /

Sonarqube
Réalisez le Lab Jenkins Sonar Pilpeline

Dev Ops

Transféré par

Droits d'auteur :

Formats disponibles

Dev Ops

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dev Ops

Transféré par

Droits d'auteur :

Formats disponibles

DEV-OPS

Formateur : JEMAL Ahmed

Pause en milieu de session

Vos questions sont les bienvenues. N’hésitez pas !

Merci d’éteindre vos téléphones

• Comprendre les principes de l’intégration continue

• Chapitre 1 : INTRODUCTION À L’INTÉGRATION CONTINUE

• Je partage mes sources.

• Je ne comprends pas, ça marche sur mon poste !?

« Il est humain de se tromper,

• Le développement doit être industrialisé pour gérer la complexité.

• Gagner du temps, car tout est automatisé.

• Développer pendant des jours et des semaines sans tester le résultat.

Les 5% de bugs découverts après la release représentent 95% des coûts de

• « … une pratique de développement logiciel où les membres d’une équipe intègrent

• Gestion centralisée du code source

• Construction de courte durée

• Toute modification du logiciel est intégrée

• Environnement d’intégration ISO production

• Tout le monde doit être au courant de ce qui se passe

• Synthèse des principes

• Publication régulière du code source

• Exécuter des constructions privées

– Pour éviter les constructions cassées, le développeur doit exécuter des

– Permet de détecter et corriger les erreurs de compilation avant la publication du

– Permet de détecter et corriger les tests en échec avant la publication du code

• Ne pas publier du code qui ne compile pas

– L’usine logicielle est alors mise hors service.

• Réparer les constructions cassées immédiatement

• Synthèse des prérequis

• Réduire les risques – Détection tardive des anomalies

• Réduit le risque de la détection tardive des anomalies.

• Réduire les risques – Non qualité

• Suite à l’exécution des tests automatiques et de l’inspection du code source.

• Réduit le risque de la non qualité logicielle.

• Réduire les risques – Logiciel non déployable

• La machine d’intégration continue est une référence.

– Le livrable du logiciel est reproductible dans le temps et dans l’espace.

– Je ne comprends pas, ça marche sur mon poste !?

• Automatiser les tâches manuelles répétitives

– Assure un gain de temps, d’effort et de budget.

– Permet à l’équipe de se concentrer sur des tâches à forte valeur ajoutée.

• Générer des versions intermédiaires du logiciel

– Une version intermédiaire du logiciel est générée à chaque intégration :

• Améliorer la visibilité projet

– Prise de décision efficace :

– Mesure des tendances :

• Synthèse des bénéfices

– Réduire les risques – Détection tardive des anomalies.

• Chapitre 1 : INTRODUCTION À L’INTÉGRATION CONTINUE

• Permet de retrouver un fichier source supprimé.

• Un dépôt (local ou distant) qui contient toutes

• Une base de données des changements apportés

• Le dépôt a une structure arborescente :

• En cas de modifications concurrentes d’une version, des splits et des

• Donner un nom explicite à une

• Permet de définir les versions

• Permet de nommer des

• Chaque développeur a sa copie avec des branches et des tags privés.