urbanisation-si

urbanisation-si

10/11 Projet informatique, passer du moyen âge à l'ère industrielle. Ne jouez pas perso, travaillez en équipe.

gestion-de-version.png

 

Pendant les phases d'inception et d'élaboration des méthodes UP (Unified Process), la discipline "Environnement" permet la mise en place des outils pour l'ensemble des acteurs du projet. Un logiciel de type GCL (Gestionnaire de Configuration Logiciel) ou VCS (Version Control System) a pour but de partager les sources, de gérer des versions et d'éventuels conflits dans un même bloc de code. Il y a quelques années, pour un projet de gestion de clients, j'étais intervenue pour mettre en place une nouvelle méthode de gestion de projet s'appuyant sur UP. Je formais alors les différents profils, chef de projet, experts métier, analystes et développeurs aux concepts d'itération, de gestion du changement, de phases et disciplines du processus unifié, de la modélisation UML, des processus métier, des Use Case, de la méthode d'estimation basée sur les UC... Une des priorités étant de valider l'architecture, j'avais recommandé Eclipse comme IDE (Environnement de Développement Intégré) ainsi que de mettre tout de suite un serveur avec Subversion qui était à l'époque le standard open source des GCL. Mais le client à ses raisons que le consultant ne connaît pas. L'outil de développement retenu fut jDeveloper d'Oracle et la mise en place de la gestion de versions fut différée pour des problèmes internes. Le projet était composé de 2 équipes de développeurs l'une à Paris et l'autre à Dijon. La "réseautique" devait installé une nouvelle ligne et configurer les firewalls  pour gérer la sécurité. J'alertais sur le fait qu'il y aurait un gros risque pour recentraliser tous les sources de Paris et Dijon dans 6 mois, qu'il y aurait des conflits et d'énormes différences ingérables manuellement. Malgré ma désapprobation  le projet démarra sans GCL ! Je structurais alors les fonctionnalités entre le sites de Paris et Dijon dans des domaines fonctionnels indépendants et les répartis entre Paris et Dijon. Les interdépendances furent bouchonnées. . Voilà vraiment la chose à ne pas faire, laissez 5 développeurs produire du code sans gestion de version. Le client aurait du mettre en place le système de GCL dés l'étude de faisabilité du projet. 

Les GCL permettent de mettre à jour ses sources à partir des modifications des autres développeurs. Et réciproquement d'enregistrer ses propres modifications pour qu'elles puissent être récupérées par l'équipe Le référentiel peut être distribué, c'este cas des outils les plus modernes comme Git (développé par Monsieur Linux Linus Torvald en personne). A partir de la version courante de l'application, celle qui évolue, appelée trunk, on peut sauvegarder des clichés(tags) correspondants par exemple à des versions stables livrées, on peut créer des branches à partir du trunk qui suivront leurs propres évolutions pour des clients différents. Lorsque 2 développeurs modifient le même bloc de code par exemple simultanément, il y a alors conflit. Tous les commits seront représentés entourés de marqueurs, il s'agira alors pour un développeur de trancher en validant une version du code et en supprimant les autres. On doit pouvoir accéder à un historique complet de tous les commits effectués et éventuellement pouvoir revenir à une ancienne version ou annuler le dernier commit. 

La grande nouveauté dans les GCL réside dans la distribution du référentiel (DVCS en anglais pour Distributed Version Control Systems). Dans un DVCS (tel que Git, MercurialBazaar ou Darcs), les clients n'extraient plus seulement la dernière version d'un fichier, mais ils dupliquent complètement le dépôt. Ainsi, si le serveur disparaît et si les systèmes collaboraient via ce serveur, n'importe quel dépôt d'un des clients peut être copié sur le serveur pour le restaurer. Chaque extraction devient une sauvegarde complète de toutes les données. De plus, un grand nombre de ces systèmes gère particulièrement bien le fait d'avoir plusieurs dépôts avec lesquels travailler, vous permettant de collaborer avec différents groupes de personnes de manières différentes simultanément dans le même projet. Cela permet la mise en place de différentes chaînes de traitement qui ne sont pas réalisables avec les systèmes centralisés, tels que les modèles hiérarchiques. 

Comme le préconise les méthodes UP, l'architecture et l'environnement doivent être stabilisés dés les premières phases d'initialisation et d'élaboration. Le système de gestion de version doit être opérationnel immédiatement, sinon gare à la facture salée du rattrapage manuel. 

 

Voir aussi :  http://bonnes-pratiques-si.eklablog.com/



12/09/2014
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 137 autres membres