Bonjour,
Avec mon groupe de travail, nous nous creusons la tête depuis plusieurs temps afin de trouver une bonne façon de numéroter nos versions développement.
Tout d'abord, un petit résumé de notre façon de travailler. Nous développons des applications de la façon suivante :
- une équipe de développeurs travaillent activement en local sur le code source en utilisant SVN pour synchroniser les sources.
- une équipe de testeurs cherchent les différents bugs sur une première machine d'intégration et notent les bugs dans bugzilla. Une fois que ces derniers sont satisfaits, ils donnent le GO pour passer l'application en pré-production.
- L'application est maintenant disponible dans l'état sur une machine de pré-production afin que les utilisateurs finaux puissent à leur tour valider et donner leur accord pour la release en production.
Lors du développement, nous découpons le projet en plusieurs milestones (ensemble cohérent de fonctionnalités orienté business). Le but étant de pouvoir mettre à disposition des utilisateurs finaux des morceaux d'application en production à chaque étape du projet et non pas une fois le projet terminé.
Pour le moment, tout ceci nous satisfait mais nous sommes un peu perdu lorsque l'on doit trouver une nomenclature efficace pour la numérotation et ceci dans le but de :
- pouvoir prévenir les testeurs qu'une nouvelle version est disponible sur la machine d'intégration et fermer les bugs présents dans bugzilla qu'elle corrige.
- pouvoir ressortir par exemple une copie de la version N-1 présentant en production un dysfonctionnement à corriger alors que nous en développement à une version N.
- utiliser de façon efficace SVN (quand utiliser un tag ? quand utiliser une branche ? Faut-il utiliser des patches pour corriger la production ou tout reconstruire ? etc.)
- utiliser de façon efficace bugzilla et avoir un suivi de la fermeture des bugs (dans quel version avons-nous tel correctif ? peut-on lié un commit SVN à bugzilla ?)
Sachant qu'une application peut évoluer dans le temps en projets et que ces projets, une fois définis, sont découpés en milestone, nous arrivons à la conclusion suivante pour les versions, elles sont du type X.Y.Z
- à la date T1, nous commençons le tout premier milestone, ainsi, le but est donc de construire la version 1.1.0. Qu'elle sera sont numéro pdt les premiers test ? 0.1.X ? 0.0.X ? 1.0.X ? Je veux dire par là, comment numéroterons-nous la première version déployé sur la machine d'intégration ? La 0.0.1 pour dire que c'est le premier déploiement en machine d'intégration dont le but est de construire le 0.1.0 en pré-production puis le 1.1.0 en production ? Dois-t-on utiliser le système de branche de SVN ? Si, oui, on dit que c'est la branche de 1.X.X ou bien 1.1.X ?
- à la date T2, nous travaillons sur une applications déjà initialisé dans un précédant projet et nous en sommes à la deuxième milestone (le but étant donc de fournir une version 2.2.0), ainsi en production, nous avons la version 2.1.X. Mais en développement, nous avons du 2.1.Y ou bien du 2.2.X ? Sachant que parfois, il faut pouvoir corriger des versions de productions sans utiliser la version actuellement en développement.
Bref, des questions que vous vous êtes très certainement tous posés (ou pas, selon...) et je voudrais bien savoir ce que vous en avez tiré comme conclusions, comme astuces, comme pièges, etc.
Si tout ceci pouvait aussi être compatibles avec les fonctionnalités de SVN et bugzilla, ça serait parfait !
Encore merci pour vos conseils !
Forum général.général projets & numéros de version - svn & bugzilla
17
avr.
2009
# Post Hook, Trac,...
Posté par Nicolas Ternisien (site web personnel) . Évalué à 0.
Si vous bossez sur une nouvelle version, c'est le trunk, point barre, vous commitez, vous commitez, vous commitez, et le jour où les objectifs de la milestone sont remplies, vous tagger le trunk, en le copiant dans le dossier tags du SVN.
Si vous êtes amenés à avoir plusieurs versions d'un même produit, les correctifs s'appliquent en commitant proprement, c'est à dire qu'un commit corrige un bug, ou ajoute 1 fonctionnalité. Il vous sera donc possible de checkouter un tags et d'y appliquer un patch, issu d'un commit SVN.
Les branches servent uniquement si vous développez plusieurs GROSSES modifications en parallèle sur le même projet, bien qu'il soit toujours possible (avec de la volonté), de travailler ensemble sur le trunk.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
# branches et numero de commit
Posté par NeoX . Évalué à 4.
ex au depart en janvier : release_janvier
tu bosses dessus, les commit augmentent... c'est la "version" du logiciel
debut fevrier, ou pour la milestone d'apres, tu envoie tout dans
release_fevrier
(ce qui sera en fait la version dont le commit est le dernier de janvier)
les numero de commit feront +1 à chaque commit
la numerotation en X.Y.Z
c'est quand tu vas distribuer ton produit
le client ayant besoin d'un nom, et d'un numero plus facile que release-457392
(457392 etant le dernier commit au moment de la distribution du produit)
# Chez nous
Posté par Croconux . Évalué à 2.
Lorsque la version 5.2, par exemple, est validée par le QA, une branche "5.2" est créée. Les développeurs commencent à travailler sur la future 5.3 et archivent toujours en "head". Ne sont archivées dans la branche que des correctifs à la pince à épiler. Des builds sont faites toutes les nuits plus éventuellement à la demande (principalement hotfix). En plus de ça, il y a un serveur de compilation qui surveille les archivages dans svn et récupère les sources à intervalle régulier pour compiler et avertir les développeurs d'un broken build.
Des branches supplémentaires peuvent être créées pour des développements risqués ou qui ne seront livrée que dans la version n+2. Ces branches sont créées au besoin et elle ne sont pas livrées telle quel mais mergées en head quand elles sont prêtes.
Chaque build livrée au QA est taggée ("5.2.3687.0" par exemple) pour garder une trace de ce qui a été livré. On n'archive jamais dans un tag. C'est un snapshot à un instant T. les correctifs sur la version de prod sont livrés par lot à intervalle assez régulier. Ces corrections sont archivées en branche ("5.2") et mergées dans le trunk. Le client passera peut être de la 5.2.1234.0 à la 5.2.2123.0 sans voir les build intermédiaires qui sont internes. On ne communique pas trop sur les numéros de build mais essentiellement sur la version globale et on parle de "sp1", "sp2",etc pour les lots de correctifs.
Pour le changelog, lors d'un commit les commentaires sont obligatoires. Si un archivage corrige un bug, on met le numéro du bug du genre #4578. Pour générer le changelog entre deux version il suffit de choper la liste des commits et de récupérer dans les messages les numéros de bugs.
[^] # Re: Chez nous
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 1.
Encore merci !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.