none
Fusion automatique de changeset liés à un workitem RRS feed

  • Question

  • Bonjour,

    Nous utilisons TFS 2012 pour gérer les développements de notre équipe.

    Nous avons récemment mis en place l'obligation de lier chaque objet d'un check-in à un Workitem de TFS.

    Notre prochaine étape serait de réaliser la fusion de l'ensemble des changeset contenus dans un workitem de façon automatique (ie: sans avoir à sélectionner chacun des changes mais uniquement le workitem). Il semblerait que Visual Studio 2012 n'offre pas cette fonctionnalité en standard.

    Pourriez-vous me dire s'il existe des add-on qui nous permettraient de faire ça ? (J'ai voulu essayer TFS Productivity Tools mais impossible de l'installer)

    De votre coté, comment assurez-vous la fusion des changements de façon cohérente entre deux branches ?

    Nous avons une 30aine de développeurs qui vont travailler de façon concurrente. Il me semble compliqué de devoir sélectionner les changesets un à un pour fusionner une partie du projet d'une branche à l'autre.

    Merci d'avance pour vos réponses,

    Thomas

    vendredi 21 février 2014 14:49

Réponses

  • Bonjour,

    Utilisez la fonction "Track Work Item" : http://blogs.msdn.com/b/slange/archive/2012/07/11/vs-tfs-2012-tidbits-merging-changes-by-work-item.aspx

    Notre prochaine étape serait de réaliser la fusion de l'ensemble des changeset contenus dans un workitem de façon automatique (ie: sans avoir à sélectionner chacun des changes mais uniquement le workitem). Il semblerait que Visual Studio 2012 n'offre pas cette fonctionnalité en standard.
    De manière générale on évite (en tout cas moi je le déconseille d'utiliser ce procédé dans les branches de développement) car avec tous les retours que j'ai eu de la part de mes clients, c'est souvent catastrophiques si le workitem n'est correctement pas renseigné au niveau des changeset. En effet, dans une équipe de développement, vous avez des stagiaires, des étourdis, ceux qui foncent pour démontrer qu'ils peuvent produire 1500 lignes de code / minute, des développeurs qui apprennent qui sont cocu,... Bref plein de raisons qui dont que les développeurs "oublient" d'associer vos modifications à des changeset (et si vous les forcer, ils se planteront de Workitem...).

    Pour éviter ce problème il y a un stratégie simple à mettre en place : Créer une branche de développement par fonctionnalité à développer. Ainsi vos développeurs de la fonctionnalité travaillent sur une branche de développement, font leur 150 checkin / minute (vous savez les fameux check-in "j'ai oublié un fichier" ou alors "correction de la compilation car j'ai oublié de vérifié que ca compilait"...

    Une fois la fonctionnalité développée, testée, validée, certifiée et tamponnée, vous faites un merge de type "S.S.P.L.T.C.L.V.E.S.D.C.C." (Sans Se Prendre La Tête Car La Vie Est Suffisemment Difficile Comme Ca) qui consiste à faire un merge (Reverse Integration) de tout le contenu de la branche vers une branche d'intégration (ou la branche Main)... Et c'est tout ! Après faudra refaire des tests d'intégration mais cette fois ci plutôt dans l'application complète car vous êtes prêt à livrer.
    Vous développeurs doivent essayer si possible de faire des Forward Integration avant de redescendre les développements dans la branche d'intégration (ou Main) afin de vérifier et corriger les impacts des autres équipes.
    Vous pouvez réutiliser la branche dans V2 de la fonctionnalité ou alors la supprimer "delete" (vous gardez ainsi son historique) mais surtout ne la détruisez pas ("destroy") !

    Est-ce que cela répond à vos interrogations ?

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    • Marqué comme réponse Aurel Bera vendredi 28 février 2014 07:52
    dimanche 23 février 2014 17:53
    Modérateur

Toutes les réponses

  • Bonjour,

    Utilisez la fonction "Track Work Item" : http://blogs.msdn.com/b/slange/archive/2012/07/11/vs-tfs-2012-tidbits-merging-changes-by-work-item.aspx

    Notre prochaine étape serait de réaliser la fusion de l'ensemble des changeset contenus dans un workitem de façon automatique (ie: sans avoir à sélectionner chacun des changes mais uniquement le workitem). Il semblerait que Visual Studio 2012 n'offre pas cette fonctionnalité en standard.
    De manière générale on évite (en tout cas moi je le déconseille d'utiliser ce procédé dans les branches de développement) car avec tous les retours que j'ai eu de la part de mes clients, c'est souvent catastrophiques si le workitem n'est correctement pas renseigné au niveau des changeset. En effet, dans une équipe de développement, vous avez des stagiaires, des étourdis, ceux qui foncent pour démontrer qu'ils peuvent produire 1500 lignes de code / minute, des développeurs qui apprennent qui sont cocu,... Bref plein de raisons qui dont que les développeurs "oublient" d'associer vos modifications à des changeset (et si vous les forcer, ils se planteront de Workitem...).

    Pour éviter ce problème il y a un stratégie simple à mettre en place : Créer une branche de développement par fonctionnalité à développer. Ainsi vos développeurs de la fonctionnalité travaillent sur une branche de développement, font leur 150 checkin / minute (vous savez les fameux check-in "j'ai oublié un fichier" ou alors "correction de la compilation car j'ai oublié de vérifié que ca compilait"...

    Une fois la fonctionnalité développée, testée, validée, certifiée et tamponnée, vous faites un merge de type "S.S.P.L.T.C.L.V.E.S.D.C.C." (Sans Se Prendre La Tête Car La Vie Est Suffisemment Difficile Comme Ca) qui consiste à faire un merge (Reverse Integration) de tout le contenu de la branche vers une branche d'intégration (ou la branche Main)... Et c'est tout ! Après faudra refaire des tests d'intégration mais cette fois ci plutôt dans l'application complète car vous êtes prêt à livrer.
    Vous développeurs doivent essayer si possible de faire des Forward Integration avant de redescendre les développements dans la branche d'intégration (ou Main) afin de vérifier et corriger les impacts des autres équipes.
    Vous pouvez réutiliser la branche dans V2 de la fonctionnalité ou alors la supprimer "delete" (vous gardez ainsi son historique) mais surtout ne la détruisez pas ("destroy") !

    Est-ce que cela répond à vos interrogations ?

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    • Marqué comme réponse Aurel Bera vendredi 28 février 2014 07:52
    dimanche 23 février 2014 17:53
    Modérateur
  • Bonjour

    Un petit retour SVP?

    Merci!

    Cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 26 février 2014 09:21