Le problème
Je suis sur un projet logiciel qui compte une dizaine de développeurs, nous partageons le code source via Mercurial. Nous avons une branche de développement et de production par version. À plusieurs reprises au cours du projet, nous avons eu le code source d'une branche, c'est-à-dire la v1, entrant dans les branches de correctifs et de maintenance pour les versions antérieures du logiciel, c'est-à-dire la v2.
Il en résulte soit du temps passé à sauvegarder le mauvais commit, soit du mauvais code (éventuellement non-QAd) atteignant et déployé dans la mauvaise branche si nous ne remarquons pas que le code est entré dans la mauvaise branche.
Notre conception / méthode de branche et fusion
v1-test v1-patch1 v1-patch2
^---------^-----------^ v1-prod
/ / \ \
-----------------------/ \ \ v1-dev
\ \ \
--------------------------\ v2-dev
\ \ \
^-------^------------- v2-prod
v2-test v2-patch1
Par conséquent, nous travaillerons sur une branche de développement de versions, jusqu'à ce qu'elle soit considérée comme prête , branchez-la pour une seule branche de test / UAT / Production, où toutes les versions et la maintenance seront effectuées. Les balises sont utilisées pour créer des versions de cette branche. Pendant que la v1 est en cours de test, une branche aura été créée pour la v2 et les développeurs commenceront à travailler sur de nouvelles fonctionnalités.
Ce qui a tendance à se produire, c'est qu'un développeur engage le travail dû à la branche v2-dev dans v1-dev ou v1-prod, ou pire, il fusionne v2-dev dans v1-prod (ou des erreurs similaires).
Nous disons à la plupart des développeurs de ne pas accéder aux branches -prod , mais le code se faufile toujours. Un groupe de développeurs plus expérimentés `s'occupe 'de la branche -prod.
Il convient de noter que même si la v2 vient de commencer le développement, il peut y avoir des correctifs assez lourds dans la v1 pour résoudre les problèmes. C'est-à-dire que v1 n'obtient pas seulement le petit patch étrange.
Ce que nous avons essayé jusqu'à présent
- Avoir une branche -prod séparée, avec des portiers. Une branche -prod devrait déclencher des avertissements par son nom et la plupart des développeurs n'ont pas besoin d'être dans cette branche. Cela n'a pas vraiment réduit le problème.
- Sensibilisation de ce problème aux développeurs, pour essayer de les rendre plus vigilants. Encore une fois, cela n'a pas été un grand succès.
Raisons possibles que je vois pour les développeurs s'engageant dans la mauvaise branche
- Une conception de branche trop complexe
- Avoir un développement actif dans plusieurs branches en parallèle. (Le projet présente des symptômes de l'utilisation du modèle d'avalanche .)
- Les développeurs ne comprennent pas assez bien le DVCS
Questions que j'ai lues qui étaient quelque peu pertinentes
J'ai lu cette question sur ne pas s'engager dans la mauvaise branche et je pense que les réponses concernant les indices visuels peuvent être utiles. Cependant, je ne suis pas entièrement convaincu que les problèmes que nous rencontrons ne sont pas les symptômes d'un problème plus fondamental.
Avec les indices visuels, nous pouvons les intégrer facilement dans la ligne de commande, mais environ la moitié de l'équipe utilise eclipse, je ne sais pas comment incorporer les indices visuels.
Question
Quelles méthodes, sous forme de logiciel, de gestion de projet ou de gouvernance, pouvons-nous utiliser pour réduire (idéalement arrêter) les engagements dans la mauvaise branche en prenant notre temps ou en salissant notre code déployé?
Un commentaire spécifique sur les raisons qui, selon moi, peuvent contribuer, comme indiqué ci-dessus, serait apprécié, mais cela ne devrait pas limiter votre réponse.