Vous êtes sur la page 1sur 20

LOG1000

Génie logiciel

C01D
LOG1000
Gestion des
versions Ingénierie logicielle
1. Définition

2. Principe de
fonctionnement

3. Outils
Gestion des versions

Département de génie informatique et de


génie logiciel
1

Avec du matériel produit par Nikolay Radoev, Mathieu Lavallée, Bram Adams et 1
Michel Gagnon
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

1. Définition

2. Principe de
fonctionnement

3. Outils

2
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

Gestion de versions (versioning) : comment
s'assurer que toute l'équipe travaille sur les
1. Définition bonnes versions des fichiers ?
2. Principe de
fonctionnement

Problème #1 : les projets logiciels sont compliqués et changent
avec le temps : certaines parties sont fixes, d'autres sont
3. Outils
souvent modifiées/ajoutées/supprimées. Il faut garder une
historique de ses changements pour pouvoir se retrouver. Quoi
garder ? Comment ?

Problème #2 : Il faut garder un contrôle sur le produit et les
modifications apportées pour ne pas permettre n'importe quelle
modification du projet et s'assurer que les exigences qu'on a
sont respectées.

Ex: le projet Chromium a près d’une
demande de changement par minute.

3
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

Une bonne gestion des versions facilite
l'intégration du code en identifiant
1. Définition clairement quel code va avec quelle
2. Principe de
fonctionnement
version.
3. Outils

Par exemple, on peut donc se retrouver avec
plusieurs versions du fichier "main.c" :
main.c 1.0
End of support 1.0
main.c 1.1
0
v1.

1
v 1.
e
eas

Bugfixes
e
eas
Rel

Bugfixes
Rel

main.c DEV

Main Development Trunk



Cela nous permet de modifier le code sans
affecter des versions fonctionnelles précédentes.4
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

Définition de la gestion des versions
logicielles :
1. Définition ●
Technique qui permet d'identifier les artéfacts du
2. Principe de
fonctionnement
projet et de gérer systématiquement les
demandes de modification, afin que le système
3. Outils
puisse conserver son intégrité au fil du temps.

En bref : être capable de savoir ce qui a changé
dans le projet et qui a fait la modification.

5
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

Quels artéfacts sont suivis par la gestion
des versions ?
1. Définition

2. Principe de
fonctionnement Code source Documents Ex.:
Ex.: (ex.:
3. Outils (ex.: fichiers SharePoint,
SVN, Content

Git.
fichiers .cpp, .h, binaires DOC, PDF Management
Systems
makefile, texte de conception, (CMS).
brut) exigences)

Ex.: bases
de données,
Données Outils Ex.:
entrepôts
statiques.
(contenu que le (configuration des gestionnaires
de paquets
logiciel doit outils utilisés, du
manipuler) workspace)

Idéalement tous ces artéfacts, mais 6


au pire seulement le code source.
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

Dans un grand projet :

Procédures de sauvegarde et de suivi des
1. Définition versions de tous les artéfacts importants.
2. Principe de – Ex.: 1M lignes de code ≈ 5000 pages de
fonctionnement
documentation.
3. Outils
– Ex.: LibreOffice ≈ 15M lignes de code !
– Cela inclut aussi les tests, les schémas de
base de données, les données des versions
des outils, etc.

Contrôle systématique des exigences et de la
conception.
– Le logiciel d'une voiture → 5000+ exigences qui
doivent changer régulièrement
– Il ne faut rien laisser échapper. Ex.:Mars Climate
Orbiter 7
LOG1000
Génie logiciel Gestion des versions
C01D
Gestion des
versions

Mise en contexte avec quelques projets proches
de votre réalité :
1. Définition Nombre de Lignes de Contributeurs Durée
fichiers code
2. Principe de
fonctionnement
TP2 INF1010 5-10 200-300 2 2 semaines
3. Outils (24h avant la
remise)

Remise finale 15-30 1500-2000 4 6 semaines


INF1900
(Projet 1)
Remise finale 150-200 10000- 6 13 semaines
LOG2990 12500
(Projet 2)
VLC 3000-4000 500 000 500+ 12 ans
(lecteur de (juste en C)
vidéos)
8
LOG1000
Génie logiciel Activités de gestion des versions
C01D
Gestion des
versions

Identifier les demandes de modification/changement.

Documenter les bogues à corriger, les nouvelles
1. Définition
fonctionnalités à ajouter.
2. Principe de

Contrôler les demandes de modification/changement.
fonctionnement

Est-ce un vrai bogue ? Est-ce réellement une
3. Outils
fonctionnalité manquante ?

Est-ce que le changement en vaut la peine ? Est-ce
trop complexe/risqué/coûteux ?

Assurer l'implémentation des demandes de
modification.

Suivant le processus de développement de
l'organisation.

Informer les personnes concernées des
modifications.
9

La modification peut avoir un impact ailleurs.
LOG1000
Génie logiciel Exemple concret avec le logiciel open source Eclipse
C01D
Gestion des
versions

Un bogue (en fait une demande de nouvelle
fonctionnalité) est soumis :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=408543
1. Définition

Un développeur soumet une première proposition de
2. Principe de
fonctionnement correction : https://git.eclipse.org/r/#/c/28831/
3. Outils ●
La proposition est rejetée après révision : c'est trop
complexe → il faut scinder le changement en trois
parties afin de faciliter les tests.

Une deuxième proposition est soumise :
https://git.eclipse.org/r/#/c/29350/2

Cette proposition n'est pas fusionnée (merged) telle
qu'elle, des réviseurs trouvent des problèmes à
corriger.

Après plusieurs versions, le code est finalement
fusionné au code du logiciel Eclipse ! 10
LOG1000
Génie logiciel Système de gestion des versions
C01D
Gestion des
versions

Outil pour gérer les implémentations des modifications
demandées, c'est-à-dire les changements ("patches)".
1. Définition

Gère l'accès de manière à ce que plusieurs personnes
puissent partager les mêmes fichiers.
2. Principe de
fonctionnement ●
Garde l'historique des modifications.
3. Outils

main.c 1.0
End of support 1.0
main.c 1.1
0
v 1.

1
v1.
e
eas

Bugfixes
e
eas
Rel

Bugfixes
Rel

main.c DEV

Main Development Trunk

11
LOG1000
Génie logiciel Système de gestion des versions
C01D
Gestion des
versions

Deux approches principales :

Blocage de fichiers : Je bloque l'accès au fichier
1. Définition
main.cpp tant que je suis en train de le modifier.
2. Principe de – Personne peut le modifier tant que je détiens
fonctionnement
l'accès.
3. Outils ●
Fusion de fichiers : Tout le monde peut modifier le
fichier main.cpp et on règlera les incohérences
(conflits) par la suite.
– Chaque membre de l'équipe travaille sur sa copie
du fichier.

12
LOG1000
Génie logiciel Blocage de fichier
C01D
Gestion des ●
Tant que le développeur ne libère par le fichier, personne
versions
d'autre ne peut y apporter des modifications.

Avantages :
1. Définition

Utile quand le fichier modifié n'est pas en texte brut.
2. Principe de
fonctionnement – Ex.: Fichier .doc, .ptt, .pdf, images.
3. Outils – Ces fichiers sont enregistrés en binaire et il est très difficile
de fusionner des versions différentes.

Parfois utile pour du travail urgent ou très complexe.

On est certain d'avoir la seule et unique version du fichier.

Inconvénients :

Empêche le travail en parallèle.

Problématique si on oublie de libérer le fichier et qu'on est absent

Peut être utilisé de manière abusive par des collègues qui
n'aiment pas fusionner les versions différentes.

N'empêche pas les incompatibilités avec d'autres fichiers.
13
– Ex.: Si un collègue renomme une dépendance.
LOG1000
Génie logiciel Fusion de fichiers
C01D
Gestion des ●
Les développeurs sont responsables de résoudre les conflits
versions
de fusion avant de pouvoir sauvegarder leurs modifications
dans l'entrepôt.
1. Définition ●
Avantages (≈ inverse du blocage) :
2. Principe de
fonctionnement

Permet le travail en parallèle.
3. Outils ●
Il n'y a pas de risque d'oublier de libérer un fichier.

Inconvénients (≈ inverse du blocage) :

Avoir des versions conflictuelles de fichiers binaires
(.doc, .ptt, .pdf, etc) est une bonne source de migraines

La résolution de conflit peut prendre du temps, surtout si
deux personnes ont modifié le même fragment de code.

Une mauvaise résolution de conflit peut amener des erreurs
dans le code/projet.

14
LOG1000
Génie logiciel Principes de fonctionnement
C01D
Gestion des J’obtiens le code du dépôt
versions int main(int argc, char **argv) {
return 0; (repository) partagé en
} ligne.
REMOTE v1
1. Définition

2. Principe de int main(int argc, char **argv) { Je fais mes modifications


fonctionnement int x = mesure(); localement.
std::cout << x;
3. Outils
return 0;
} Quand je suis satisfait, je
soumet (commit) le
int mesure() { changement et je le
return 5; pousse (push) sur le
} LOCAL dépôt partagé en ligne.

int main(int argc, char **argv) {


Le dépôt partagé possède
int x = mesure();
maintenant ma dernière
std::cout << x;
version de code. Tout le
return 0;
monde peut l’obtenir.
}

int mesure() {
return 5; 15
} REMOTE v2
LOG1000
Génie logiciel Principes de fonctionnement
C01D
Gestion des int main(int argc, char **argv) { J’obtiens le code du dépôt
versions int x = mesure(); partagé en ligne.
std::cout << x;
return 0;
1. Définition }
Ça ne marche pas ... On a
2. Principe de int calcul() { fait des changements qui
fonctionnement
return 5; ont brisé quelque chose ...
3. Outils } REMOTE v3

int main(int argc, char **argv) { Pas de problème, je n’ai


int x = mesure(); qu’à retourner à une
std::cout << x; version précédente
return 0; (revert) qui fonctionnait
} (v2)
Je peux aussi comparer
int mesure() { (diff) les version 2 et 3
return 5; pour voir ce qui a été
} REMOTE v2 changé et pourquoi ça ne
marchait pas.

16
LOG1000
Génie logiciel Principes de fonctionnement : fusion
C01D
Gestion des int main(int argc, char **argv) { On essaie de soumettre
versions int x = mesure(); votre code en ligne, mais
std::cout << x; ça ne fonctionne pas.
return 0; Quelqu’un d’autre a
1. Définition } soumis des changements
au même fichier !
2. Principe de <<<<<<< HEAD
fonctionnement
int mesure() {
3. Outils =======
Il y a un conflit (conflict) ...
int calcul() {
entre notre version
>>>>>>> 77976da
(HEAD) et la version qui
return 5; se trouve sur le remote,
} LOCAL
soit la version 77976da.

int main(int argc, char **argv) {


int x = calcul_mesure(); Les marques de conflit ont
été mises directement
std::cout << x;
dans le code. Il faut donc
return 0;
l’éditer afin de dire à l’outil
}
quelle version garder (la
nôtre, la précédente, ou
int calcul_mesure() {
un mélange des deux).
return 5;
} LOCAL 17
LOG1000
Génie logiciel Systèmes de gestion de versions
C01D
Gestion des ●
Il existe une très grande quantité d'outils de gestion des
versions
versions. Parmi les plus populaires :

1. Définition

SVN (Subversion) :
2. Principe de
– Fonctionne par bloquage de fichiers.
fonctionnement ●
Git :
3. Outils
– Fonctionne par fusion de fichiers.
– Un des système les plus populaires.

Perforce :
– Fonctionne par bloquage de fichiers.
– Adapté pour des gros projets (jeux vidéo par
exemple).

Microsoft TFS (Team Foundation System) / VSTS
(Visual Studio Team System) :
– Inclut des outils de gestion de projet. 18
LOG1000
Génie logiciel Systèmes de gestion de versions
C01D
Gestion des
versions

SVN a été populaire pendant très longtemps, mais
est lentement remplacé par Git.
1. Définition

Entre 70% et 80% des projets à code ouvert sont
2. Principe de
gérés avec Git, en hausse continue.
fonctionnement ●
La même proportion pour SVN, en chute libre.
3. Outils

Le projet intégrateur de 1ère année (et tous les
autres après) et les TPs en LOG1000 se font donc
sur Git.

Il faut donc savoir comment s'en servir.

Il existe des interfaces graphiques pour Git, mais il est
préférable de commencer en bonne vieille ligne de
commande.

Git est déjà installé sur les postes de l'école et sur la
machine virtuelle fournie par l'école.
19
LOG1000
Génie logiciel Distribué vs Centralisé
C01D
Gestion des ●
SVN et Perforce sont des systèmes de gestion de versions
versions
centralisés.

Seul le serveur garde l'historique des versions. Les clients ne font
1. Définition que manipuler les fichiers.
2. Principe de
fonctionnement

Git est un système de gestion de versions distribué.
3. Outils

Les clients n'ont pas seulement des fichiers, mais dupliquent
complètement l'historique sur le serveur.

Approche de SVN (centralisé) 20


Approche de Git (distribué)

Vous aimerez peut-être aussi