Modèles pour l'intégration continue et DVCS

Nous utilisons actuellement Subversion et TeamCity, nous allons passer à Mercurial (en particulier Kiln car nous sommes des utilisateurs de FogBugz).

Évidemment, cela entraînera des changements - espérons-le, des améliorations - dans nos modèles de développement (tous les deux!), Mais le seul problème avec lequel je me heurte est de savoir comment structurer les choses afin que nous profitions toujours des avantages de l'intégration continue / de notre serveur CI ( qu'il existe et restera des avantages est une donnée, dont la discussion sort du cadre de cette question).

Avec SVN, nous nous engageons à un nombre limité de référentiels centraux - en fait un par projet (plus ou moins une solution Visual Studio) afin qu'il soit facile de déclencher une construction et d'obtenir l'assurance que tous les fichiers ont été validés et qu'il n'y a pas dépendances errantes, etc., etc. Mais si nous voulons tirer parti de mercurial, nous voudrons avoir plus d'instances de référentiel - où je m'attends à ce que les changements se dirigent généralement vers un référentiel "live" définitif. Le problème avec lequel je me bats est que le repo en direct me semble trop "tard" pour déclencher mes builds CI OTOH une build CI par projet par développeur est probablement excessive (et cause d'autres problèmes).

Je pêche un peu mais c'est parce que l'une des choses qu'un dépôt central de subversion donne (moi, avec notre configuration!) Est beaucoup de clarté sur ce qu'il faut construire quand.

nb Je ne pose pas de questions sur la mécanique de l'utilisation de mercurial avec une intégration continue - j'ai ce traitement pour un projet personnel, ses modèles et structures et sa pratique / flux de travail que j'essaie de faire tourner la tête.

Tout d'abord, avoir plusieurs versions par projet dans TeamCity est vraiment la voie à suivre. La nature de la plate-forme le rend vraiment facile - le bouton de copie est là pour une raison.

Dans tous les cas, lorsque nous étions sur SVN, nous avons généralement exécuté 2 versions pour chaque projet - une pointée vers la ligne de développement principale (dans notre cas, le tronc) et une pointant vers notre branche de publication. Nous avons reporté cette configuration de build sur HG tout en suivant un modèle de branchement similaire à celui-ci . Le seul véritable défi a été de trouver un nouveau schwea funk sur les numéros de build maintenant que nous ne pouvions plus utiliser le numéro de révision SVN actuel.

Nous essayons d'encourager les gens à pousser relativement souvent, surtout quand il y a beaucoup de travail en cours et que nous voulions des cycles de rétroaction plus rapides. Ce n'est pas parce que c'est un DCVS que vous ne devez pousser qu'une fois par jour ou quelque chose.

Nous utilisons Kiln depuis environ un an maintenant et avons essayé plusieurs choses différentes. Nous avons fini par utiliser des branches nommées (par opposition aux clones de branches) avec la stratégie de branchement suivante:

• par défaut suit le développement "terminé"
• les succursales de fonction suivent le travail en cours
• libérer les branches suivre les points où nous avons libéré de défaut

Ainsi, le travail commence par la création d'une branche de fonctionnalité à partir de la pointe par défaut actuelle . Lorsque la branche de fonctionnalité est terminée *, la branche est fermée et fusionnée à nouveau par défaut .

À un moment donné, nous décidons que nous sommes prêts à publier, nous créons donc une nouvelle branche de publication à partir de l'astuce actuelle par défaut . Cela nous permet d'apporter des modifications au code qui est actuellement en production en validant la branche de publication tout en permettant le développement actif sur les branches de fonctionnalité et par défaut .

Quant à l'intégration continue, nous faisons deux choses:

• Une intégration "toujours active" qui surveille l'état par défaut
• Nouvelles intégrations pour chaque branche de publication

Le travail de branche par défaut nous permet de savoir que notre arbre source principal est toujours stable - les travaux de branche de version nous permettent de savoir que ces branches sont stables et nous fournissent la sortie de génération dont nous avons besoin pour pousser une version en production.

_{* Notre définition de «terminé» est que la fonctionnalité est à jour avec les fusions par défaut et a été approuvée lors de la révision du code.}

Si vous passez à un DVCS, comme Hg, vous obtenez non seulement la "partie distribuée", vous obtenez également toute la puissance d'une bonne ramification et fusion.

Étant donné que vous aurez maintenant un bon suivi des problèmes et un bon SCM ... pourquoi ne pas créer une branche pour chaque tâche?

Le modèle "branche par tâche" n'est pas nouveau (consultez le livre de Berczuk) mais c'est définitivement quelque chose à essayer.

Je l'ai expliqué en détail ici , et les avantages et les inconvénients de CI vs "contrôlé" ici .