Comment puis-je gérer correctement les validations, prévenir les conflits de fonctionnalités et gérer les dépendances avec un VCS?

C'est devenu un facteur ennuyeux de travailler avec de grandes équipes: comment gérer les enregistrements et éviter les conflits de fonctionnalités et gérer correctement les dépendances avec le contrôle des sources?

Actuellement sur mon lieu de travail, nous utilisons TFS 2008 et nous migrons vers TFS 2010 début décembre. Tout d'abord, tout contrôle de source est meilleur que rien, mais quelle approche quelqu'un a-t-il trouvé utile pour empêcher plusieurs enregistrements et restaurations dans tout l'historique du contrôle de source? Est-ce qu'un tronc volatile est la meilleure façon d'aller ou de se dériver lorsque vous implémentez une nouvelle fonctionnalité et une fois que vous êtes heureux de le réintégrer dans le tronc?

J'aimerais vraiment entendre les expériences d'autres personnes et peut-être quelques meilleures pratiques pour gérer le contrôle des sources.

TFS? Courez pour les collines! Partez aussi vite que possible. Il fait beaucoup de choses différentes, mais aucune n'est aussi bonne que les meilleurs outils disponibles.

Mais sérieusement:

Une fois que vous avez un système de contrôle de version décent (SVN, GIT, etc.), je recommanderais de définir des règles pour la gestion des succursales, par exemple quand créer des succursales, pour quoi, quand fusionner, qui, et bien plus encore.

Jusqu'à récemment, nous utilisions une seule branche pour les nouveaux développements («tronc»). Pour une version, nous créerions une branche hors du tronc. L'AQ finale serait effectuée dans cette branche et une fois terminée, nous publierions (nous sommes sur des versions mensuelles).

Nous sommes passés au concept de «pas de courrier indésirable dans le coffre» pour réduire le risque d'horaire. Ce concept contient essentiellement une règle par laquelle vous créez des branches pour le travail de développement distinctes du tronc. Par exemple, vous pouvez avoir une branche distincte pour une fonctionnalité, pour une petite équipe de développement ou similaire. Nous utilisons des «épopées» pour décrire une petite fonctionnalité ou une partie libérable d'une fonctionnalité et créer une branche pour chaque épopée. Au moins une fois par jour, tous les changements du tronc sont fusionnés dans la branche épique. La clé est une bonne prise en charge de la fusion par le contrôle de version ou un outil séparé (par exemple la fusion à trois voies). L'AQ pour l'épopée se ferait sur la branche épique. Une fois passée, la branche épique serait fusionnée dans le tronc et un test d'intégration serait exécuté. Nous avons encore des succursales pour les sorties.

Avec les branches épiques, nous avons considérablement réduit le risque de calendrier car nous sommes maintenant en mesure de sortir du coffre et d'inclure toutes les épopées qui ont été fusionnées avec succès dans le coffre. Les épopées qui ne sont pas complètes manquent le bus et feront la prochaine sortie (le mois prochain).

Bien sûr, cela ne peut fonctionner que dans notre environnement. Très probablement, vous aurez des facteurs différents des nôtres qui influeront sur les meilleurs choix pour la gestion des succursales.

Par exemple, si vous avez une équipe avec beaucoup de personnes travaillant à distance et n'étant pas toujours connectées au serveur de contrôle de version, alors vous voudrez utiliser un système de contrôle de version qui prend en charge un modèle distribué. GIT et quelques autres tomberaient dans cette catégorie. TFS à ma connaissance nécessite une connexion au serveur pour rendre les fichiers accessibles en écriture (corrigé dans la version 2010?).

J'espère avoir pu montrer qu'il n'y a pas de "taille unique". Commencez par vos processus en particulier la gestion des succursales, déterminez les exigences et enfin sélectionnez l'outil qui correspond le mieux à vos besoins. C'est peut-être TFS, peut-être pas.

Je préconise une branche par fonctionnalité car elle permet une grande flexibilité lors du choix des fonctionnalités à expédier et de celles à reporter.

La façon dont cela fonctionne dans votre situation dépend de la façon dont votre VCS gère les branches et, plus important encore, la fusion. Les DVCS comme Git et Mercurial en font un exercice relativement trivial. SVN moins. J'ai réussi à éviter TFS bien que j'aie beaucoup lu à ce sujet, la plupart du temps peu compliqué, je le crains. Si vous êtes bloqué avec TFS, faites une petite version pilote basée sur une fonctionnalité par branche et voyez à quel point la fusion se déroule pour vous.

Tout d'abord, un avertissement. Il est difficile de dire quelle est la meilleure façon de gérer votre source, car nous ne savons pas comment votre ou vos équipes travaillent au quotidien.

Généralement, il vaut mieux travailler sur le tronc. Pour chaque version majeure, branchez-la - afin que les correctifs de bogues pour la version de la version se trouvent sur la branche qui peut être fusionnée dans le tronc. Tous les développeurs travaillent sur le tronc et commettent du code régulièrement (au minimum une fois par jour).

La fusion de nouveau code dans minimise régulièrement la douleur de la fusion de gros morceaux de code dans une phase d'intégration massive. En étalant la douleur, vous la ressentirez moins. Plus les membres de votre équipe valident le code, moins ils devront fusionner - car ils seront toujours sur la dernière source.

Je n'ai jamais utilisé TFS 2008/2010 mais d'après ce que j'ai lu dans divers forums, il y a beaucoup de négativité à utiliser TFS pour le contrôle de version. Cela m'a permis de rester loin de TFS jusqu'à présent.

J'utilise actuellement SVN et Git, je les trouve tous les deux bons pour les petites équipes ou les équipes individuelles, mais je ne recommanderais pas personnellement SVN pour une grande équipe.

J'ai mes yeux sur PlasticSCM et j'essaierai de le faire dans un proche avenir.

Je m'excuse de ne pas avoir répondu à votre question spécifique, j'aurais posté un commentaire si mes privilèges m'y avaient permis.

Je pense que git rend tous les autres logiciels de contrôle de source obsolètes. Le branchement et la fusion sont faciles, et s'il y a des problèmes, ils sont contenus, mais de nombreux problèmes sont évités par la façon dont il encourage les commits, les branchements et les fusions très fréquents. Chaque utilisateur obtient une copie complète du dépôt (cela peut être élagué, mais je travaille avec une base de code assez énorme et ce n'est pas un problème), il y a donc quelque chose d'une sauvegarde automatique. Les validations / push / pull sont rapides, et l'une des choses les plus importantes est qu'il rompt le couplage entre le nom de fichier et le suivi. Les données du fichier, y compris le nom et le chemin, sont un objet de données référencé par un nœud d'arborescence, indépendant des chemins. Ce n'est pas seulement plus sûr, mais certains types de problèmes "ne faites jamais ça" dans quelque chose comme SVN ne sont pas un problème. Il peut être utilisé comme une configuration de concentrateur traditionnelle ou peer to peer, et ces utilisations peuvent être mélangées librement dans la même configuration. Il est cryptographiquement sécurisé contre les insertions non documentées. Et c'est très rapide.

Je trouve que je l'utilise à la maison maintenant tout le temps, juste pour garder une trace des documents et les synchroniser entre les ordinateurs, car il est plus facile de les valider et de les envoyer au serveur de fichiers que de les sauvegarder sur le serveur ou de les y enregistrer.

L'inconvénient est un peu une courbe d'apprentissage abrupte, car elle casse toutes les règles auxquelles les gens sont habitués avec le contrôle de source, de manière subtile, mais c'est une courte courbe d'apprentissage abrupte.

Certaines des bonnes pratiques que nous suivons vraiment et nous ont beaucoup aidés:

1) Assurez-vous que vous ne disposez pas d'une copie inscriptible du fichier dans votre section locale et que vous vérifiez toujours pour modifier. (Si vous devez parfois travailler localement, essayez de le fusionner dans le contrôle de source avant EOD.)

2) Étiquetez vos fichiers périodiquement, après de petits jalons importants.

3) Donnez de bons commentaires sur le paiement ou l'enregistrement. Cela vous aidera lorsque vous réviserez, parfois vous n'avez pas besoin d'ouvrir et de comparer les versions.

comment gérez-vous les enregistrements et empêchez-vous les conflits de fonctionnalités et gérez-vous correctement les dépendances avec le contrôle de code source?

C'est, d'après mon PDV, une tâche à deux facteurs: vous devez le faire du côté technique (branchement bon et facile et à l'épreuve des balles | fusion | audit, etc.) et de la gestion (politique bien établie "quoi" "quand" "comment"). Deux ou même trois niveaux de code de séparation dans ALM: quelque chose comme "stable" (test unitaire réussi), "instable" (toutes les fonctionnalités incluses sont terminées, mais l'application en tant que produit a des questions après l'intégration / oui, cela peut arriver /) et " travaux en cours ". De cette façon, un chef de projet approprié peut réduire l'interférence du travail de développeur séparé en commun.

TFS (que je n'utilise pas, utilise et n'utiliserai pas) a, AFAIK, des problèmes fondamentaux dans son aspect de gestion du contrôle de source. Je fais juste un lien ici vers certains des textes de James McKay:

• Team Foundation Server est le Lotus Notes des outils de contrôle de version
• Fusion sans fondement dans le serveur Team Foundation - pourquoi?

Un article très agréable et récent qui compare et contraste de manière claire et concise quelques façons différentes de travailler avec le contrôle de source est ici: Source Control Done Right .

Je ne pense pas qu'il existe une stratégie / meilleure pratique pour l'utilisation du contrôle de code source. Les équipes matures qui travaillent ensemble depuis longtemps éprouvent beaucoup moins de «douleur» dans ce domaine même si elles ne suivent pas exactement les «meilleures pratiques» populaires.

Quant aux outils ... Peu importe presque. Ce qui compte vraiment, c'est que tout le monde dans votre équipe soit sur la même page en ce qui concerne l'utilisation. Cela signifie que tout le monde doit comprendre comment la ligne de code est gérée et ce qu'ils doivent faire. Et de toute façon, dans la pratique, vous n'avez généralement pas le choix de l'outil à utiliser. Tirez le meilleur parti de tout ce que vous utilisez.