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

12

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.

continuous-integration dvcs

— Murph
source

Pourquoi pensez-vous qu'il est trop tard pour déclencher des builds à partir du référentiel central / "live"?

— c_maker

Si vous n'y êtes pas déjà allé, je vous suggère de vous rendre sur le site d'échange de pile de four ( kiln.stackexchange.com ). Ils ont un peu de contenu sur la façon de configurer cela (en voici un: kiln.stackexchange.com/questions/29/… . Personnellement, nous utilisons une branche par fonctionnalité, et pointons le serveur de génération vers notre branche "maître". )

— Chris Phillips

@Chris - J'ai, il n'y en a pas vraiment, ne pas aborder le problème CI ...

— Murph

2

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.

— Wyatt Barnett
source

Wyatt, à mon avis, cela devrait se produire lorsque vous avez une unité de travail terminée (ish) - l'un des avantages de DVCS est que nous pouvons valider, localement, du code qui est cassé. Je n'aime vraiment pas l'idée de faire quoi que ce soit sur un calendrier parce que c'est la fin de la journée. Il y a un problème distinct de "sauvegarde", qui - pour moi - concerne la mise en place d'une règle pour pousser latéralement - lors de la validation - vers un autre clone qui n'existe que pour être une sauvegarde.

— Murph

2

Truc il y a quelle est la définition de l'unité de travail? Est-ce "cette fonctionnalité est terminée" ou est-ce "cette brique est posée avec succès". Nous tendons vers ce dernier, en particulier avec ce modèle de ramification où il existe une branche de développement clairement délimitée. Il est préférable de laisser les choses se casser pour présenter des branches. Ceux qui durent longtemps peuvent également obtenir des builds CI si possible. Surtout s'il y a plusieurs cuisiniers dans la cuisine.

— Wyatt Barnett

Je suis d'accord avec votre définition de «l'unité de travail», c'est pourquoi je me bats un peu avec mon modèle global (qui a déjà plusieurs versions par projet de manière différente pour accueillir à la fois les versions «CI» et les versions «déploiement»). Vous avez raison, la réponse est de câbler beaucoup de builds donc à la fin mon vrai problème va être de faire signer le chèque! Le modèle de branchement référencé semble également correct. Considérant toujours le modèle global (et permettre que cela soit encore ajusté pour permettre des spécificités de kilnhg)

— Murph

2

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.}

— Chris Phillips
source

1

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 .

— psantosl
source

Je dirais "mieux" plutôt que "bon" car j'ai heureusement, avec enthousiasme et réussi à la fois la ramification des fonctionnalités et de la maintenance et la fusion avec la subversion (-:

— Murph