Organisation du développement

Etats

Stable

Version de prod ici AMDA STABLE pour l'usage courant des utilisateurs extérieurs.

Testing

Version stable en test, en fait les dernières fonctionalités developpées empaquetées chaque jour (le nightly build) ici AMDA TESTING

c'est ici que l'on vient tester les fonctionnalités que l'on a demandées et relever les bugs éventuels.

Experimental

Les versions en cours de developpement sur les machines des developpeurs

• Elena
• Richard

ces derniers accès peuvent bien sur être cassés puisque le developpeur est justement en train d'y travailler.

Suivi de versions: CVS

Le développement concurentiel (programmation du même projet à plusieurs intervenants) implique une gestion fine des versions des fichiers. Il existe des outils dédiés à cette tâche, et nous utiliserons un serveur CVS, car c'est un logiciel que nous maitrisons déjà.

Accès

Deux mode d'accès sont prévus sur le serveur CVS:

• anonyme
• authentifié

Dans le premier cas, on peut récupérer tout le projet en développement en lecture seule

export CVSROOT=:pserver:anonymous@iapetus.cesr.fr:/var/lib/cvs_pub
cvs login #password: anon
cvs co amda
cd amda/

Dans le second, il suffit de s'assurer d'avoir un compte sur iapetus, puis suivre les même étapes en fournissant son login à la place d'_anonymous_, de même que son mot de passe.

On peut aussi préférablement utiliser l'accès ssh de la façons suivante:

export CVSROOT=iapetus.cesr.fr:/var/lib/cvs_pub
export CVS_RSH=ssh
cvs co amda
cd amda
ChecklistPluginDev

Branches

La disctinction des différents états de développement d'AMDA n'est pas que conceptuelle.

Supposons par exemple que nous avons récemment mis en production une version stable de notre projet. Projetons nous dans le futur et appelons cette version la 2.0, aboutissement notre optimisme concrétisé.

Pendant les semaines qui suivent, les utilisateurs se ruent, nombreux, sur cette nouvelle mouture aux fonctionnalités débridées.

Dans le même temps, les développeurs ne choment pas: la 2.1 doit être terminée impérativement hier ... euh non, le mois prochain, et ceux ci travaillent déjà sur une version expérimentale.

Ce qui devait arriver arriva, un bug majeur est signalé sur la version de production, la 2.0.

Il faut donc corriger ce bug et remettre en production une nouvelle version stable. Mais on ne peut pas raisonnablement se contenter de corriger le bug sur la version expérimentale: celle ci est en cours de développement et beaucoup trop instable pour être offerte aux utilisateurs.

Il faut donc revenir à la version stable et modifier cette version indépendamment de l'expérimentale. Cette manipulation n'est possible que grace au mécanisme d'embranchement de CVS.

Ainsi, à chaque livraison, on fera naitre une branche destinés à la maintenance de la version de production parallèlement au développement des version futures.

Dans un premier temps nous maintiendrons deux branches:

1. "AMDA_TESTING-0_5" : la dernière version stable
2. la branche de développement principale, non taggée

Concrètement cela se réalise par la commande tag de cvs de la façons suivante:

cvs tag -b AMDA_TESTING-0_5

Ultérieurement, on pourra récupérer cette partie de la branche avec la commande:

cvs checkout -r AMDA_TESTING-0_5

et commencer les correction de bug sur cette branche.

Modules

Amda est d'ores et déjà une application modulaire, et nous répercutons cette architecture sur le repository CVS à travers les noms de modules qui permettent de ne récupérer qu'une partie du projet.

Cela est possible grace aux alias de modules de CVS que l'on utilise comme de simple module:

export CVSROOT=:pserver:hitier@iapetus:/var/lib/cvs_pub
cvs   login
cvs   co amdaWs
cd amdaWs/

par exemple

amdaWs

le client web services

• amda-app
• amda-client

Commentaires

-- RichardHitier - 06 Dec 2006