Subversion – Quelqu’un devrait-il se développer hors du coffre?

Lorsque vous utilisez Subversion, les développeurs doivent-ils travailler hors du tronc ou le tronc doit-il être utilisé uniquement pour les fusions de la twig de chaque développeur et surveillé par un service d’continuous integration?

Il existe deux stratégies de base:

  • trunk instable – le trunk contient toujours le dernier code, les twigs sont faites pour faire les release
  • trunk stable – le code est développé dans les twigs et archivé dans le coffre uniquement lorsque le test est terminé et que les versions sont exécutées à partir du tronc

Ce que vous utilisez est dans une certaine mesure une question de préférence personnelle. Mais à côté de l’un ou l’autre, les développeurs individuels devraient utiliser des twigs pour leurs propres développements expérimentaux.

Donc, comme d’habitude, pas de réponse définitive!

Cela dépend de l’ampleur des changements. Une bonne pratique générale est que le tronc devrait toujours être compilable, mais cela ne signifie pas nécessairement que les développeurs ne peuvent pas travailler sur le tronc pour de petites modifications / corrections de bugs – après tout, c’est l’une des raisons pour lesquelles une copie de travail est nécessaire. vous pouvez vous assurer que quelque chose comstack avant de le valider.

Les modifications plus importantes ou les ajouts de fonctionnalités doivent presque toujours être intégrés à la twig jusqu’à ce qu’ils soient prêts pour l’intégration afin de ne pas interférer avec d’autres développements.

Il existe plusieurs méthodes pour travailler avec les systèmes de contrôle de version pour le développement parallèle. Il n’y a rien de mal à celui que vous proposez ci-dessus – mais il y a des avantages et des inconvénients à chacun. J’ai travaillé dans les deux sens.

Le développement hors ligne et la suppression des twigs de publication sont bien, mais si vous devez exécuter une version de production d’urgence, vous devez corriger la twig Release et la relancer, c’est-à-dire créer une twig dans votre système CI.

Travailler dans des twigs et préserver le tronc principal (surveillance avec un système d’continuous integration) est également une bonne chose, mais peut entraîner des conflits avec les développeurs de plusieurs twigs effectuant des modifications.

Consultez également le site suivant:

http://www.cmcrossroads.com/bradapp/acme/branching/

Il aborde un certain nombre de modèles de twigment pour le développement parallèle, notamment:

  • S1. Mainline
  • S2. Maintenance parallèle / développement
  • S3. Regroupement des rejets
  • S4. Ligne d’amarrage
  • S5. Lignes d’intégration par étapes
  • S6. Changement de queue de propagation
  • S7. Codeline de tiers
  • S8. Lignes intérieures / extérieures

Je pense que cela dépend vraiment de l’ampleur de votre opération. Jusqu’à peut-être 5 à 10 développeurs, tout le monde s’engageant dans le tronc devrait vraiment être OK. Mais, bien sûr, tout le monde doit garder à l’esprit que la ligne doit toujours être compilable. S’ils travaillent sur des modifications majeures qui ne se comstackront pas pendant un certain temps, ils devront alors passer à une twig.

Lorsque vous utilisez Subversion, il est courant que tout le monde travaille à partir du tronc. Si un développeur particulier travaille sur une fonctionnalité importante ou “expérimentale”, il peut être judicieux de créer une twig distincte pour ce travail, qui pourra être fusionnée ultérieurement dans la ligne de réseau.

Cependant, la méthode que vous décrivez, chaque développeur ayant sa propre twig, est plus proche de Git que de Subversion. Si c’est ce que vous préférez, je vous recommande fortement d’utiliser Git à la place.

Avec Git, il n’est pas nécessaire d’utiliser une sorte de serveur d’continuous integration pour surveiller les différentes twigs. Au lieu de cela, chaque développeur a sa propre twig, qu’il peut simplement fusionner dans la twig principale quand il le souhaite.

J’ai presque toujours travaillé sur des équipes développées sur le tronc – ça marche bien. Je ne dis pas que c’est la meilleure idée ou quoi que ce soit, mais ce n’est pas quelque chose qui mérite d’être contré si ça va vous faire virer.

Cependant, notre système est toujours complet et utilise souvent aussi le CI. Chaque développeur doit être au courant du cycle update / rebuild / retest / commit (non pas infaillible, mais ça marche assez bien).

Hmph, ça fait mal quand je pense au nombre de nos logiciels qui fonctionnent “Well Enough”.

Il y a un argument à faire pour que les développeurs soient obligés de travailler sur le tronc.

Si vous les laissez se twigr, certains seront tentés de maintenir ces twigs indéfiniment et de se synchroniser avec la ligne à intervalles réguliers. Cela conduira inévitablement à des opérations de fusion compliquées, qui à leur tour génèrent des bogues.

En forçant tout le monde sur le tronc, ils doivent restr proches de la tête, donc il y aura moins de risque d’introduction de bogues avec de mauvaises fusions. De plus, comme tout le monde exécute du code à jour, il est plus probable que les bogues apparaissent à mesure qu’ils progressent, et les correctifs seront validés plus rapidement.

Bien entendu, une fonction importante doit parfois être organisée séparément, mais dans ce cas, une exception spécialement approuvée peut être effectuée.

Notre coffre ne fait que fusionner et corriger les bogues urgents. Quand on a un nouveau projet, on twig le tronc, on se développe sur la twig, on rebase depuis le tronc si une autre twig a été fusionnée dans le tronc et quand on est prêt à tester, on déploie la twig. Lorsque le test est correct, nous fusionnons avec le tronc et nous mettons en version bêta. Avant la fusion, nous faisons une version sur le tronc pour éviter les problèmes.

Après que la bêta était OK, nous lançons pour produire.

Je travaille sur une version 3.0 de notre produit aujourd’hui et archiver mes modifications de code dans le tronc. La sortie est encore à plusieurs semaines.

Un collègue expérimente certaines fonctionnalités qui pourraient le rendre en 4.0, mais certainement pas en 3.0. Elle vérifie ses affaires dans une twig séparée. Il serait faux de vérifier ce genre de choses dans le coffre.

Un autre collaborateur corrige des bogues dans la version 2.5, que nous avons déjà expédiés à un client. Il les vérifie dans la twig 2.5 pour des raisons évidentes.

Donc, pour répondre à la question principale (si tout le monde se développe hors du tronc, ma réponse est non. HTH

PS à propos de la fusion. Nous pourrions fusionner de manière sélective des éléments de la twig 2.5 vers le tronc plus tard, mais pas du tronc vers la twig. La fusion entre le tronc et la twig 4.0 peut se faire dans les deux sens.

Comme l’a dit Neil Butterworth , cela dépend; plusieurs moyens valables existent.

Cependant, personnellement, je vous recommande d’avoir un coffre stable et de faire tous les développements majeurs sur les twigs temporaires. (C’est-à-dire que seules les petites modifications indépendantes qui seront complètement effectuées avec un seul commit doivent aller directement au tronc.) Pour éviter que les twigs de longue durée ne se trouvent trop loin de la ligne principale, twigs, au moins quotidiennement. Oh, et tout devrait être surveillé par CI – pas seulement le coffre, mais aussi toutes les twigs de développement. Surtout avec Hudson, c’est un cliché et provoque très peu de frais généraux.

Si vous êtes intéressé par la manière dont nous avons appliqué cela, il y a plus de détails dans cette réponse . (Je détesterais me répéter trop 🙂 🙂

Je recommande en fait cette approche même si une seule équipe travaille sur la base de code, et même si tout le monde travaille sur la même fonctionnalité / modification. Pourquoi? Eh bien, dans mon expérience (à moins que les choses – comme les calendriers de publication, les exigences, etc. – soient très prévisibles dans votre environnement), il est certainement avantageux d’avoir toujours votre tronc dans une forme détachable .

J’ai des développeurs qui créent des twigs de projet ou modifient les twigs de requête / bogue du tronc, puis fusionnent, donc oui, les développeurs travaillent sur le tronc, mais ce qui se passe dans les twigs “fusion” est contrôlé outil de contrôle ou processus.

Je pense que c’est assez bien couvert par cette question

oui, cela devrait être votre copie de travail pour la publication. Toutes vos twigs doivent être des versions précédentes de votre code.

Cela dépend entièrement de votre calendrier de sortie. Si tous les travaux actuellement en cours d’enregistrement sont destinés à être lancés immédiatement, ils peuvent tous être archivés dans une zone, telle que la jonction. S’il rest du travail à faire pendant que d’autres, encore inachevés, doivent sortir en premier, le premier code à sortir pourrait être validé dans le tronc, et le code suivant dans sa propre twig, ou inversement.

Vous devriez trouver que fusionner et rafraîchir des twigs peut être un casse-tête où les choses vont parfois mal. Donc, naturellement, essayer de minimiser cela aurait du sens. L’idée générale du contrôle de la source est que tout le monde peut travailler au même endroit.

Souvent, lorsque vous avez des équipes plus importantes, le calendrier de publication est organisé par sous-équipes et leurs projets et ceux-ci ont leurs propres succursales.

Oui.
Cela n’a aucun sens de faire de votre dernière succursale votre version la plus récente. Ensuite, votre coffre devient obsolète de vos twigs.

Je pense que si vous êtes agile et libérez-le par petites étapes dans quelques semaines, vous devriez développer dans le tronc. De cette façon, vous disposez de la dernière version du tronc, il est construit en permanence, peut-être est-il cassé, mais sera corrigé rapidement et lorsque vous êtes prêt à sortir, étiquetez-le et libérez-le. De cette façon, il n’ya pas de problème de fusion des twigs.

Je pense que je voudrais aussi append que si vous développez dans des twigs, vous ne pouvez pas être agile. Le développement dans les twigs ne fonctionne que dans les cascades.

Je pense que les outils que vous utilisez sont également un facteur important.

  • Si vous utilisez Subversion, le tronc instable fonctionnera probablement mieux pour vous.
  • Si vous utilisez GIT, le trunk stable sera beaucoup plus facile que Subversion.

Dans mon entreprise, nous avons adopté un modèle de développement de tronc stable avec un code en cours de développement et des tests complets sur les twigs avant d’être fusionné au tronc. Mais je trouve cette pratique assez décourageante car il faut souvent des mois avant que l’équipe de validation ne teste complètement les twigs. Nous nous retrouvons donc avec ces twigs pendant des mois avant de pouvoir les ramener dans le coffre.

Le revers de la médaille serait d’utiliser un développement de trunk instable avec toutes les modifications apscopes dans le trunk tout le temps, mais notre équipe de validation commence alors à se plaindre de ne pas avoir confiance dans le code car les modifications sont toujours présentes. pas d’isolement

Il semble donc qu’aucune de ces approches n’est vraiment optimale. Existe-t-il une approche plus optimale pour une équipe où la validation peut prendre beaucoup de temps?