SUBVERSION un serveur de sources libre le jeudi 31 janvier 2008 – Association Lolita V 1.0 – Michel Cerdini.

Présentation au sujet: "SUBVERSION un serveur de sources libre le jeudi 31 janvier 2008 – Association Lolita V 1.0 – Michel Cerdini."— Transcription de la présentation:

1 SUBVERSION un serveur de sources libre le jeudi 31 janvier 2008 – Association Lolita V 1.0 – Michel Cerdini

2 Pour qui ? Pour qui ? –Les programmeurs et développeurs –Tous les languages de programmation (PHP, PL-SQL, C, C#, Perl, Python, Ruby, Script Shell, Delphi etc.) –Utile quand on est seul –Encore plus utile quand on est en groupe ! Pour quoi faire ? Pour quoi faire ? –Conserver une copie de toutes les versions modifiées des codes sources –Comparer les versions entre elles, revenir en arrière –Savoir qui a modifié quelle partie d'un code –Gérer les conflits en cas de modifications concurantes Un serveur de sources, c'est quoi ?

3 Un premier exemple (1/2) Contexte Contexte –Un développeur de site web en php –Travaille sous Windows –Serveur Web sous Linux –Serveur de sources sous Linux Objectif Objectif –Voir ce qui a été modifié la dernière fois sur le fichier « account_history.php »

4 Un premier exemple (2/2)

5 Un remplaçant un CVS Un remplaçant un CVS –« Concurrent Versions System », qui a démarré entre 86 et 89 –Encore utilisé dans les projets opensouce –SVN (abrégé de Subversion) corrige ses principaux défauts Les avantages de SVN vs CVS Les avantages de SVN vs CVS –Historique des dossiers (et pas uniquement des fichiers) –Historique des renommages, déplacements et copies de fichiers –Meilleures résolutions automatique des modifications simultan. Centralisé ou décentralisé ? Centralisé ou décentralisé ? –Centralisé : un seul serveur sur lequel tous les développeurs travaillent –Décentralisé : plusieurs serveurs qui se mettent à jour mutuellement deux à deux –SVK : extention à SVN pour le basculer en serveur décentralisé Subversion un serveur de source centralisé

6 Phase 1 : préparation du serveur SVN L'administrateur système L'administrateur système –Installe Subversion sur un serveur (Unix ou Windows) –Créé un espace de stockage appelé « repository » ou « dépôt » –Déclare les utilisateurs ayant accès au repository –Configure le moyen d'accès (accès natif, via HTTP, au travers d'une connexion sécurisée SSH etc.) Installation sous Debian Installation sous Debian –« apt-get install subversion » –Puis « svnadmin create /home/svn/monrepository » Serveur SVN

7 Phase 2 : préparation du poste des développeurs Installation du client SVN Installation du client SVN –Il permet de se connecter au serveur –Windows : TortoiseSVN graphique et complètement intégré à l'environnement –Sur tout Unix : svn en mode texte –Linux : KdeSVN entièrement graphique –Mac : SmartSVN, tout graphique –Eclipse : plugin Subclipse Chaque client discute avec le serveur Chaque client discute avec le serveur –Les clients ne discutent pas entre eux Serveur SVN

8 Phase 3 : récupérer le contenu du repository Opération réalisée qu'une seule fois (la 1ère fois) Opération réalisée qu'une seule fois (la 1ère fois) –Dans un dossier vide sur poste, on indique l'adresse du repository : « svn+ssh://cerdini@priv1.super.com/home/svn/monrepository » –Cette opération copie l'intégralité du repository dans le dossier

9 Phase 3 : récupérer le contenu du repository (sous Windows) Client graphique utilisé TortoiseSVN

10 Phase 4 : c'est terminé, on peut travailler ! Le développeur programme sur son poste de travail Le développeur programme sur son poste de travail –Déconnecté du serveur, il travaille « offline » –Sa copie locale est appelée « Working copy » ou « Copie de travail » –Quand les modifications effectuées sur le code sont stables, l'opération de publication de l'ensemble des fichiers modifiés s'appelle « Commit » –L'opération inverse, qui consiste à récupérer les mises à jour publiées par d'autres développeur sur le serveur s'appelle « Update »

11 La notion de Révision : porte un numéro unique qui augmente à chaque nouvelle publication

12 La notion de Révision : peut (doit !) porter un commentaire qui résume les opérations effectuées sur les fichiers publiés

13 Les commandes les plus utilisées 1/2 add add –Pour ajouter un fichier (ou un dossier) au repository : en effet tous les fichiers d'un dossier versionné ne sont pas nécessairement eux-même versionné commit commit –Enregistre les modifications locales dans le repository en créant une nouvelle révision copy copy –Pour copier un fichier ou dossier dans un autre emplacement delete delete –Efface un fichier ou dossier (mais ne sera toujours visite dans les révisions antérieurs)

14 Les commandes les plus utilisées 2/2 diff diff –Compare des révisions différentes d'un même fichier log log –Affiche l'historique des modifications move move –Déplace un fichier d'un emplacement à un autre status status –Donne la liste des fichiers qui ont été modifiés (qui seront publiés lors du prochain commit) update update –Met à jour sa copie locale des modifications effecutées sur le serveur (doit toujours se faire avant un commit)

15 Quelques consignes Toujours utiliser les commandes SVN pour déplacer / copier / supprimer un fichier Toujours utiliser les commandes SVN pour déplacer / copier / supprimer un fichier –Cela permet de conserver l'historique des modifications –Cela évite de revoir apparaître le fichier au prochain update ! Ne pas supprimer le dossier caché «.svn » Ne pas supprimer le dossier caché «.svn » –Chaque dossier versionné a un sous-dossier «.svn » –Il contient un ensemble de données nécessaire au fonctionnement de subversion Toujours faire un update avant un commit Toujours faire un update avant un commit Faire des commits très régulièrement Faire des commits très régulièrement –Cela réduit drastiquement le nombre de conflit

16 Résolution manuelle d'un conflit Bizarrement, très peu de conflits se produisent Bizarrement, très peu de conflits se produisent –On constate moins de 5% de conflits sur les gros projets opensource

17 Autre notions intéressantes Pose de verrous Pose de verrous –A utiliser avec parcémonie (normalement pas nécessaire) Création de branche Création de branche –Permet d'isoler dans une ligne de développement séparé les modifications effectuées à partir d'une révision (pour expérimenter quelque chose sans déranger la ligne de développement principal par exemple) –A l'issue, possibilité de refusionner avec le « tronc » ou « trunc » Création et importation de patchs Création et importation de patchs –Permet la production de fichiers de différences entre votre copie de travail et la révision de base (à l'inverse de l'intégralité du code source)

18 Organisation idéale Séparation des rôles Séparation des rôles –Les développeurs développent et livrent leur code sur le serveur de source –Le maître d'oeuvre d'assure de la cohérence de l'ensemble et monte les révisions stable sur un serveur de test visible du client –Une la révision validée, le maître d'oeuvre la communique à l'exploitation qui à la charge de la mise en production et du fonctionnement de l'ensemble Serveur SVN Développeur s Serveur de test Le client valide (maître d'ouvrage) Le chef de projet vérifie (maître d'oeuvre) Serveur de production L'exploitation met en production sur ordre du maître d'oeuvre, à une révision X

19 Quelques liens Serveur Subversion Serveur Subversion –Site officiel : http://subversion.tigris.org/ –Dernière version : 1.4.6 du 20 décembre 2007 Client graphique Windows : TortoiseSVN Client graphique Windows : TortoiseSVN –Site officiel : http://tortoisesvn.tigris.org/ –Excellente documentation en français : http://tortoisesvn.net/support –Dernière version : 1.4.7 du 5 janvier 2008 Hébergement gratuit de repository Hébergement gratuit de repository –Unfuddle : http://unfuddle.com/ projet pas nécessairement opensource mais limité à 15mb –SourceForge : http://sourceforge.net projet opensource obligatoire

20 Intégration des îcones à l'explorateur Windows TortoiseSVN en français Le menu contextuel en français

21 TortoiseSVN Windows La livraison d'une mise à jour (svn commit) A l'issue, le compte rendu...

22 Au delà des serveurs de sources Autres briques des ateliers de développement Autres briques des ateliers de développement –Le serveur de source : la brique de base –Le générateur de documentation : code documenté par tag (cf JavaDOC), récupéré tous les jours sur le serveur de source et publiés automatiquement sur un ensemble de pages web –Un outil d'intégration continue : récupère tous les jours les codes sources, compile automatiquement les projets, et remonte les éventuelles erreurs sur une page web (cf CruiseControl etc.) –Les tests unitaires : combinés à l'intégration continue, valide les codes au travers des jeux de données de test et s'assure de la non régression des nouvelles versions (cf JUnit, DUnit etc.) –La production d'états statistiques : pour établir le % de code couvert par la documentation et les tests unitaires...

23 Des questions ?