Désolé pour ce long post, mais je pense que ça vaut le coup.
Je viens de commencer avec une petite boutique .NET qui fonctionne un peu différemment des autres endroits où j'ai travaillé. Contrairement à mes positions précédentes, le logiciel écrit ici est destiné à plusieurs clients et tous les clients ne reçoivent pas la dernière version du logiciel en même temps. En tant que tel, il n'y a pas de «version de production actuelle». Lorsqu'un client obtient une mise à jour, il obtient également toutes les fonctionnalités ajoutées au logiciel depuis sa dernière mise à jour, ce qui pourrait être il y a longtemps. Le logiciel est hautement configurable et les fonctionnalités peuvent être activées et désactivées: ce que l'on appelle des «basculements de fonctionnalités». Les cycles de publication sont très serrés ici, en fait ils ne sont pas planifiés: lorsqu'une fonctionnalité est terminée, le logiciel est déployé chez le client concerné.
L'an dernier, l'équipe est passée de Visual Source Safe à Team Foundation Server. Le problème est qu'ils utilisent toujours TFS comme s'il s'agissait de VSS et appliquent des verrous Checkout sur une seule branche de code. Chaque fois qu'un correctif de bogue est mis sur le terrain (même pour un seul client), ils construisent simplement tout ce qui se trouve dans TFS, teste le bogue a été corrigé et déploie le client! (Moi-même issu d'un arrière-plan de logiciels pharmaceutiques et d'appareils médicaux, c'est incroyable!). Le résultat est que le code de développement à moitié cuit est mis en production sans même être testé. Les bogues glissent toujours dans les versions, mais souvent un client qui vient de recevoir une version ne verra pas ces bogues s'il n'utilise pas la fonctionnalité dans laquelle il se trouve. Le directeur sait que c'est un problème car la société commence à se développer tous d'un coup avec l'arrivée de gros clients et d'autres plus petits.
On m'a demandé d'examiner les options de contrôle des sources afin d'éliminer le déploiement de bogues ou de code inachevé, mais de ne pas sacrifier la nature quelque peu asynchrone des versions des équipes. J'ai utilisé VSS, TFS, SVN et Bazaar dans ma carrière, mais TFS est l'endroit où la plupart de mon expérience a été.
Auparavant, la plupart des équipes avec lesquelles j'ai travaillé utilisent une solution à deux ou trois branches de Dev-Test-Prod, où pendant un mois les développeurs travaillent directement dans Dev et ensuite les modifications sont fusionnées dans Test puis Prod, ou promues "quand c'est fait" plutôt que sur un cycle fixe. Des versions automatisées ont été utilisées, à l'aide du régulateur de vitesse ou de la constitution d'équipe. Dans mon travail précédent, Bazaar était utilisé assis sur le dessus de SVN: les développeurs ont travaillé dans leurs propres petites branches de fonctionnalités, puis ont poussé leurs changements vers SVN (qui était lié à TeamCity). C'était bien car il était facile d'isoler les changements et de les partager avec les branches d'autres peuples.
Avec ces deux modèles, il y avait une branche centrale de développement et de production (et parfois de test) à travers laquelle le code était poussé (et des étiquettes étaient utilisées pour marquer les builds dans la prod à partir desquelles les versions étaient faites ... et celles-ci étaient transformées en branches pour corriger les bogues) vers les versions et fusionné en dev). Cependant, cela ne convient pas vraiment à la façon de travailler ici: il n'y a pas d'ordre quand différentes fonctionnalités seront publiées, elles sont poussées lorsqu'elles sont terminées.
Avec cette exigence, l'approche «d'intégration continue» telle que je la vois se décompose. Pour sortir une nouvelle fonctionnalité avec une intégration continue, elle doit être poussée via dev-test-prod et qui capturera tout travail inachevé dans dev.
Je pense que pour surmonter cela, nous devrions descendre dans un modèle ramifié fortement doté de PAS de branches dev-test-prod, plutôt que la source devrait exister sous la forme d'une série de branches de fonctionnalités qui, lorsque le travail de développement est terminé, sont verrouillées, testées, fixes, verrouillées , testé puis publié. D'autres branches de fonctionnalités peuvent saisir les modifications d'autres branches quand elles en ont besoin / veulent, donc finalement toutes les modifications sont absorbées par tous les autres. Cela correspond très bien à un pur modèle Bazaar de ce que j'ai vécu lors de mon dernier emploi.
Aussi flexible que cela puisse paraître, il semble étrange de ne pas avoir de branche de tronc de développement ou de production quelque part, et je crains que les branches ne se réintègrent jamais, ou que de petites modifications tardives ne soient jamais transmises à d'autres branches et que les développeurs se plaignent fusionner des catastrophes ...
Que pensent les gens à ce sujet?
Une deuxième dernière question: je suis quelque peu confus quant à la définition exacte du contrôle de source distribué: certaines personnes semblent suggérer qu'il s'agit simplement de ne pas avoir de référentiel central comme TFS ou SVN, certains disent qu'il s'agit d'être déconnecté (SVN est déconnecté à 90% et TFS a un mode hors ligne parfaitement fonctionnel) et d'autres disent qu'il s'agit de la fonction Branching et de la facilité de fusion entre les branches sans relation parent-enfant (TFS a également une fusion sans fondement!). C'est peut-être une deuxième question!