Comment puis-je brancher mon code de manière à rendre les tests possibles sans contaminer la ligne de base?

Question

En utilisant TFS, nous avons les éléments suivants:

• Une référence principale
• Une branche de développement pour chaque effort de développement. Ceux-ci sont fusionnés à la ligne de base.
• Une branche de version créée avec chaque version. Les corrections de bogues sont apportées ici, publiées et fusionnées avec la base de référence.
• En utilisant des étagères, nous pouvons partager du code entre les branches de développement si nécessaire sans contaminer la ligne de base. Utile pour les révisions de code.
• Lorsque nous livrons nos modifications de développement à la ligne de base, nous avons une version automatisée qui démarre et place automatiquement nos modifications sur le serveur de test.

Le problème est que les analystes commerciaux ne peuvent pas voir nos modifications tant qu'elles ne sont pas sur le serveur de test, et actuellement, le seul moyen d'obtenir nos modifications sur le serveur de test est de les vérifier dans la base de référence. Donc, si le BA trouve quelque chose qui ne va pas, le code est malheureusement déjà en ligne de base et nous devrons nous donner la peine de le retirer.

Existe-t-il un moyen de changer notre stratégie ou processus de branchement pour obtenir aux BA ce qu'ils veulent voir sans contaminer notre base de référence?

Answer 1

Votre stratégie de branchement correspond exactement à ce que nous avons décidé dans mon entreprise. Je ne pense pas que le problème vient de votre stratégie de branchement, je pense que le problème est que vous devez vérifier les modifications dans la base de référence afin de les appliquer au serveur de test.

Dans mon entreprise, les modifications ne sont pas intégrées dans la base de référence tant qu'elles ne sont pas promues et exécutées en production. Les branches de version sont ce qui est déployé sur les serveurs de test ... si des bogues sont trouvés, ou si les BA veulent changer quelque chose, nous n'avons pas à nous soucier de supprimer les modifications de la ligne de base.

Cependant, si vous avez beaucoup de versions simultanées, cela peut devenir difficile de fusionner toutes les versions ensemble avant de les passer en production, car vous ne fusionnez dans la ligne de base que plus tard dans le processus. Dans mon entreprise, nous avons un calendrier de sortie très strict et nous essayons de n'avoir qu'une seule version en production à la fois. Pour cette raison, attendre de fusionner la version dans la ligne de base jusqu'à ce que la version soit promue en production n'a pas créé de problèmes pour nous, ni de travail supplémentaire jusqu'à présent ...

À quelle fréquence sortez-vous? Seriez-vous en mesure de déployer des branches de version sur vos serveurs de test et de faire en sorte que la référence représente ce qui est actuellement déployé en production?

(J'en ferais un commentaire, mais je travaille toujours pour obtenir ce privilège ...)

Answer 2

Je ne préférerais pas cette approche, je suggérerais:

Une ligne de base principale qui contient du code stabilisé.Le code sera fusionné dans cette branche à partir de la branche de publication respective uniquement après une publication réussie.

Une branche Release qui est créée à partir de Main pour chaque version.Cette branche sera utilisée pour générer des versions de version et sera déployée dans l'environnement de test.

Une branche de développement créée à partir de Release Branch, elle sera utilisée pour les efforts de développement et sera fusionnée avec Release lorsque je serai prêt à donner ma version à tester.