Préparation aux outils d'intégration et développement continus

Analyse des besoins : C'est la phase initiale où les besoins des utilisateurs sont recueillis et
analysés. Cela implique souvent des discussions avec les utilisateurs ou les clients, ainsi que des
recherches pour comprendre le contexte d'utilisation du logiciel.

Conception : Cette phase consiste à définir l'architecture du système, les modèles de données,
les interfaces utilisateur et d'autres aspects techniques du logiciel. C'est la phase où l'on prend les
décisions clés sur la façon dont le logiciel va fonctionner.

Implémentation : C'est la phase où le code du logiciel est réellement écrit. Cela implique souvent
de diviser le logiciel en différentes parties ou modules, qui peuvent être développés et testés
individuellement.

Intégration : Après que les différentes parties du logiciel ont été développées et testées, elles sont
combinées en un seul système. C'est souvent une phase complexe, car elle peut révéler des
problèmes d'interaction entre les différentes parties du logiciel qui n'étaient pas apparents
lorsqu'elles étaient développées individuellement.

Test : Une fois que le logiciel a été intégré, il est testé pour s'assurer qu'il fonctionne comme
prévu. Cela peut impliquer une variété de types de tests, y compris des tests fonctionnels (pour
vérifier que le logiciel fait ce qu'il est censé faire), des tests de performance (pour vérifier qu'il
fonctionne suffisamment rapidement), des tests de sécurité (pour vérifier qu'il n'est pas vulnérable
aux attaques), et d'autres.

Déploiement : Après que le logiciel a été testé et que tous les problèmes ont été résolus, il est
déployé pour être utilisé par les utilisateurs finaux. Cela peut impliquer de le mettre en ligne sur un
serveur, de le distribuer sur des disques ou de le télécharger sur une boutique d'applications.

Maintenance et évolution : Une fois que le logiciel a été déployé, il doit être maintenu. Cela peut
impliquer de corriger des bugs, d'ajouter de nouvelles fonctionnalités, d'améliorer les
performances, de mettre à jour le logiciel pour prendre en compte les nouvelles technologies ou
normes, et d'autres tâches.

L'intégration continue, le déploiement continu et le développement continu sont des pratiques qui
font partie de la méthodologie DevOps. Elles visent à rendre le processus de développement de
logiciels plus efficace et plus fiable.
Intégration continue (Continuous Integration, CI) : Cette pratique consiste à intégrer
régulièrement le travail des développeurs dans un dépôt central. Chaque intégration est vérifiée
par une construction automatique (compilation et exécution de tests) pour détecter les erreurs le
plus tôt possible. Cela encourage une culture de développement où les développeurs intègrent
leur travail fréquemment, généralement plusieurs fois par jour.

Déploiement continu (Continuous Deployment, CD) : Cette pratique est une extension de
l'intégration continue, où chaque modification du code, après avoir passé avec succès le
processus d'intégration continue, est automatiquement déployée en production. Cela permet
d'accélérer le processus de livraison de nouvelles fonctionnalités et corrections aux utilisateurs
finaux.

Livraison continue (Continuous Delivery, aussi CD) : C'est un compromis entre l'intégration
continue et le déploiement continu. Chaque modification du code qui passe le processus
d'intégration continue est automatiquement mise en état de pouvoir être déployée en production,
mais le déploiement en production n'est pas automatique, il nécessite une approbation manuelle.
Cela donne plus de contrôle sur ce qui est déployé et quand.

Ces trois pratiques ont pour objectif de réduire les risques associés au développement de logiciels
en rendant le processus plus prévisible et en permettant de détecter et de corriger les erreurs plus
rapidement. Elles ont également pour effet de rendre le processus de développement plus réactif,
en permettant de livrer rapidement de nouvelles fonctionnalités et corrections aux utilisateurs.

Partie 2 :

Dans le modèle traditionnel de développement de logiciels, souvent illustré par le modèle en

cascade ou en V, les différentes phases du projet sont généralement séquentielles et distinctes.
Par exemple, la phase de développement de code n'a lieu qu'après la fin de la phase de
conception, et la phase de test n'a lieu qu'après que tout le code a été développé.

L'intégration continue, le déploiement continu et la livraison continue viennent changer cette

approche de plusieurs manières :

Détection précoce des problèmes : Dans le modèle traditionnel, l'intégration du code a souvent
lieu tard dans le cycle de développement, ce qui signifie que les problèmes d'intégration ne sont
découverts qu'à un stade avancé du projet. Avec l'intégration continue, les modifications de code
sont intégrées et testées régulièrement, souvent plusieurs fois par jour, ce qui permet de découvrir
et de corriger les problèmes d'intégration beaucoup plus tôt.
Réduction du temps de mise sur le marché : Dans le modèle traditionnel, le déploiement en
production n'a lieu qu'après la fin de la phase de test, ce qui peut prendre beaucoup de temps.
Avec le déploiement continu, chaque modification de code qui passe les tests est
automatiquement déployée en production, ce qui permet de livrer les nouvelles fonctionnalités et
corrections aux utilisateurs plus rapidement.

Amélioration de la qualité : Dans le modèle traditionnel, les tests sont souvent une phase
distincte qui a lieu après le développement du code. Avec l'intégration continue, les tests sont
intégrés dans le processus de développement et sont exécutés à chaque intégration de code, ce
qui permet de détecter et de corriger les erreurs plus tôt et d'améliorer la qualité du logiciel.

Flexibilité : Dans le modèle traditionnel, les décisions de conception sont souvent prises au début
du projet et sont difficiles à changer par la suite. Avec le déploiement continu et la livraison
continue, il est plus facile d'apporter des modifications au logiciel en réponse aux commentaires
des utilisateurs ou aux changements dans l'environnement d'entreprise.

Ces pratiques s'intègrent généralement dans une approche de développement de logiciels plus
agile, qui met l'accent sur l'adaptabilité, la collaboration et la livraison continue de valeur pour
l'utilisateur.

Q1. Quelles sont les principales phases de développement d’un logiciel par une équipe ?
Q2. Définition des principales phases et les potentiels problèmes qu’il peut y avoir à la phase
d’implémentation.
Q3. Qu’est-ce qu’un projet ?
Q4. Qu’est-ce que le diagramme de Gantt ?
Q5. Définition des concepts :
- d'intégration continue ;
- de déploiement continu ;
- de développement continu.
Q6. Quels sont les avantages de ces pratiques par rapport aux anciennes méthodes de
développement de logiciel ?
Q7. Quelles sont les principales plateformes d’Intégration, de développement et de déploiement
continue ?
- Gitlab
- Github
- Jenkins
On constate que les plateformes Gitla et Github sont basées sur l’outil Git qu’il convient d’étudier.
1 git : concepts, installation et mise en œuvre

L’objectif de cette fiche est de vous initier à 10 commandes de base de l’outil de gestion de
versions GIT. La maîtrise de git est importante pour un développeur afin de se familiariser avec les
plateformes DevOps comme Gitlab ou Github.

1.1 Concepts de git

Git est un outil de contrôle de version créé par Linus Torvalds pour suivre l'évolution de son propre
code. Le contrôle de version ou versioning est une bonne pratique dans la création de logiciels, car
il favorise l'intégration et le développement continus en permettant aux développeurs de suivre
l'évolution de leur travail au fil du temps. La maîtrise de Git est essentielle pour un développeur
afin de tirer pleinement parti des plateformes telles que GitHub et GitLab, offrant des
fonctionnalités supplémentaires pour faciliter la collaboration et l'intégration continue.
1.2 Installation

Pour installer git en environnement Ubuntu, commencez par mettre à jour la liste des paquets

disponibles sur votre système avec la commande, puis installez le paquet git. Si l’installation se

déroule bien, vous devez avoir les informations sur votre version de git avec la commande git --

version.

root@bessan-pc:/home/bessan# apt update

root@bessan-pc:/home/bessan# apt install git

root@bessan-pc:/home/bessan# git --version

1.3 10 Commandes git de base à connaître

1. Git config

Avec Git, chaque modification que vous faites dans un dépôt doit être signée avec votre nom et

votre e-mail. La commande git config sert justement à donner ces informations à git avant de

démarrer n’importe quel projet.

root@bessan-pc:/home/bessan# git config --global user.name "LABO RTN"

root@bessan-pc:/home/bessan# git config --global user.email "bessan.melckior@ec2lt.sn"

Vous pouvez vérifier les informations renseignées avec l’option --list de la commande git config.
root@bessan-pc:/home/bessan/CICD3D# git config --list

2. Git init

Un dépôt Git est un conteneur pour l'ensemble de votre projet qui permet de gérer et de suivre les

modifications, les branches et les contributions des différents développeurs.

root@bessan-pc:/home/bessan# mkdir CICD3D

root@bessan-pc:/home/bessan# cd CICD3D/

root@bessan-pc:/home/bessan/CICD3D# git init

3. Git add

Pour ajouter un ou plusieurs fichiers à votre projet, il suffit d’utiliser la commande git add.

root@bessan-pc:/home/bessan/CICD3D# git add description_projet.txt acteurs_projet.txt

4. Git commit

Un commit est une action qui permet de sauvegarder un ensemble de modifications apportées à

un dépôt Git. Il enregistre une capture instantanée de l'état des fichiers dans le dépôt à un moment

donné, avec un message décrivant les modifications apportées grâce à l’option -m.

root@bessan-pc:/home/bessan/CICD3D# git commit -m "TDR"

5. Git status

Après avoir initialisé votre dépôt Git et ajouté des fichiers, il est important de connaître l'état de

votre dépôt. La commande git status vous permet d'obtenir des informations sur les fichiers

modifiés.

Assurez-vous d'être dans le dossier du dépôt Git avant de tapez la commande.

root@bessan-pc:/home/bessan/CICD3D# git status

Après chaque modification dans vos fichiers, il faut reprendre les commandes git add et git

commit.

6. git diff

La commande La commande git diff sert à afficher les différences entre votre répertoire de travail

et la dernière révision enregistrée (commit) dans votre dépôt Git.

TD 1 à faire
7. Git log

La commande git log permet de voir l’historique des commits effectués dans votre dépôt.

root@bessan-pc:/home/bessan/CICD3D# git log

8. Git branch

Les branches sont utiles pour travailler sur différentes fonctionnalités ou correctifs en parallèle,

sans impacter la branche principale.

• Pour créer une nouvelle branche appelée ‘developpement’, utilisez la commande git branch

comme suit :

root@bessan-pc:/home/bessan/CICD3D# git branch developpement

• Pour afficher la liste des branches locales, tapez simplement la commande git branch

• Pour renommer la branche ‘developpement’ en ‘alpha’, utilisez l’option -m comme suit :

root@bessan-pc:/home/bessan/CICD3D# git branch -m developpement alpha

 • Pour supprimer la branche ‘alpha’, utilisez l’option -d ou (-D pour forcer la suppression)

comme suit :

root@bessan-pc:/home/bessan/CICD3D# git branch -d alpha

Il existe d’autres options spécifiques aux branches distantes que nous allons découvrir dans la

suite du cours.

9. Git checkout

• Pour basculer sur une branche, utiliser la commande git checkout suivie du nom de

la branche comme suit :

root@bessan-pc:/home/bessan/CICD3D# git checkout beta

• Pour créer une nouvelle branche et y basculer en même temps, utilisez l’option -b

comme suit :

root@bessan-pc:/home/bessan/CICD3D# git checkout -b release

10. Git merge

Après avoir travaillé sur une branche ‘release’ et validé les modifications de vos différents fichiers,

vous devez fusionner les deux branches (master et release) avec la commande git merge.

Notez qu’il faut d’abord utiliser la commande git checkout pour basculer sur la branche master

avant de faire la fusion, car la fusion se fait dans la branche active.

root@bessan-pc:/home/bessan/CICD3D# git merge release

NB : Si des conflits surviennent, Git vous demandera de les résoudre manuellement avant que la

fusion se fasse. En d’autres termes, il faudra ouvrir le fichier sur la branche master à l’origine du

conflit afin de l’adapter aux modifications de la branche release avant de procéder à la fusion.

N’oubliez pas de faire un git add et un git commit après la modification.

TD N°2 A FAIRE