DVCS, comme Git, est-il inapproprié pour les équipes utilisant l'intégration continue?

Question

Les processus de développement de mon équipe reposent sur la intégration continue . Les seules branches que nous créons sont les branches de maintenance lorsque nous publions, mais dans le cas contraire, les développeurs sont tenus de s’engager régulièrement (quotidiennement, voire plus souvent) dans trunk, afin que le travail de tout le monde soit toujours intégré, constamment testé et tout ce qui est bien.

D'après ce que je sais de DVCS , il est idéal pour créer des branches. J'ai travaillé il y a quelques années dans une équipe où cela aurait été très utile, car chaque développement a été réalisé sur une branche et n'a été fusionné qu'une fois terminé et testé. Mais c’était une philosophie différente de l’intégration continue.

Mais il me semble que pour une équipe qui utilise l'intégration continue, les fonctionnalités remarquables des outils DVCS telles que Git ne serait pas particulièrement pertinent et pourrait même entraver le processus d'intégration continue si la fusion des modifications nécessitait des étapes supplémentaires qui pourraient être oubliées.

Je suis sûr que le DVCS présente d’autres avantages (par exemple, s’engager est très rapide car il est local, il est probable qu’une fusion avec la branche principale pourrait se produire en arrière-plan pendant que le développeur continue de travailler).

Mais pour cette question, je suis intéressé par la façon dont les équipes qui utilisent le DVCS et l’intégration continue réconcilient les deux philosophies apparemment contradictoires. Je suis surtout intéressé à entendre des personnes qui le font réellement.

Answer 1

En réalité, DVCS a grandement facilité l'intégration continue.

Avec VCS central, chaque développeur a le droit de s’engager directement dans le coffre et peut donc valider un code erroné. CI le détectera après coup. Il est donc possible d’avoir le coffre cassé même avec le CI.

D'autre part, les opérations de base dans le monde DVCS sont la création de branches et la fusion. Étant donné que la fusion est explicite et qu'un processus distinct est associé à une validation dans la ligne de réseau, il est toujours possible de vérifier le résultat d'une fusion avant que celle-ci n'atterrisse sur le tronc. Je n'ai pas d'expérience avec Git, mais les développeurs de Bazaar VCS ont utilisé cette technique avec succès pendant au moins trois ans et demi à l'aide de l'outil PQM.

En gros, le flux de travail PQM se présente comme suit: le développeur publie sa branche pour pouvoir le fusionner, puis envoie un courrier électronique spécial au bot PQM avec des instructions de fusion. Lorsque PQM reçoit une demande de fusion, il crée une branche d'intégration distincte (copie de la ligne de réseau), puis fusionne la branche du développeur et exécute des tests sur le code résultant. Si tous les tests sont réussis, la branche d'intégration est poussée dans la jonction, sinon le développeur recevra un courrier électronique avec le journal des tests ayant échoué.

L'exécution de tous les tests pour le projet Bazaar prend du temps, mais les tests sont exécutés à la demande sur un serveur séparé. Les développeurs ne seront pas bloqués par les fusions et pourront continuer à travailler sur d'autres tâches.

À la suite d'un flux de travail de fusion basé sur PQM, la jonction bzr n'est jamais interrompue (du moins tant qu'il y a suffisamment de tests d'acceptation et de régression).

Answer 2

Étant donné que tous les DVCS peuvent être utilisés avec un flux de travail utilisant un référentiel centralisé, il n'y a pas de problème. La stratégie indique que le développeur doit appliquer ses modifications au référentiel central exactement de la même façon que les modifications de stratégie dictées sont validées sur un VCS non distribué. Les outils supplémentaires qui permettent au développeur d’éditer des ensembles de correctifs ne constituent en aucun cas un obstacle, mais facilitent en fait la création d’une base de code maintenable.

Answer 3

L'utilisation d'un DVCS tel que Git ne vous empêche pas de vous engager régulièrement dans un référentiel central. Cependant, cela signifie que vous pouvez effectuer des validations intermédiaires localement et ne transférer les modifications dans le référentiel central qu'une fois l'opération terminée.

De cette manière, vous bénéficiez des avantages du contrôle de source même lorsque vous mettez en œuvre une fonctionnalité à mi-chemin, sans interrompre la construction pour les autres développeurs.

Answer 4

Les outils d'intégration continue tels que Hudson prennent en charge DVCS. Je suppose donc qu'il est possible de réconcilier l'intégration continue avec le contrôle de version distribuée.

Tout d’abord, je pense qu’avec DVCS, l’utilisation de flux de travaux tels que le CI de flux de travaux de branche thématique pourrait être moins nécessaire. Deuxièmement, vous pouvez configurer un référentiel d’intégration continue (unique, central) vers lequel vous poussez lorsque vous êtes prêt, et les raccords sont configurés par CI.

Ajouté le 07-08-2009:

Voir par exemple le nettoyage printanier de l'intégration continue publié sur le blog GitHub. .

Answer 5

Deux idées auxquelles j'ai trouvé de l'aide expliquent ceci:

• DVCS sépare les commits des fusions.
• CI s'exécute sur un référentiel de votre choix.

Le cœur du problème est donc de savoir comment les fusions sont effectuées dans les référentiels sur lesquels vous souhaitez exécuter un outil de CI. Vous pouvez choisir d’avoir un seul référentiel lorsque vous démarrez.