TFS 2010 Solutions Multiples et Build avec Check-in Garanti

Question

J'ai deux solutions dans leur dossier correspondant, par exemple :

1. SolutionA\SolutionsA.sln
2. SolutionB\SolutionB.sln

Chaque solution a une compilation Check-in sécurisée configurée ; c'est-à-dire deux définitions de compilation GatedSolutionA et GatedSolutionB.

Maintenant, la situation est la suivante : si je fais des modifications dans les deux dossiers en même temps, TFS affiche une boîte de dialogue pour sélectionner la compilation (menu déroulant avec GatedSolutionA, GatedSolutionB) à exécuter contre le changement. Mon changement provoque des erreurs dans la solution B et des modifications sans erreur dans la Solution A. Autrement dit, la compilation GatedSolutionB échouera mais GatedSolutionA réussira.

Lorsque je sélectionne GatedSolutionA pour compiler contre mes modifications, TFS les valide, ce qui laisse la solution B dans un état cassé et le but de la validation sécurisée est vain pour la solution B.

Si je change le déclencheur en CI pour les définitions de compilation, TFS met en file d'attente les deux compilations.

Ce que je cherche, c'est le même comportement, c'est-à-dire que toutes les compilations sécurisées sont mises en file d'attente et si l'une d'elles échoue, le changement doit être rejeté.

Remarque : Je ne veux pas créer une seule définition de compilation pour les deux solutions. De plus, je sais que nous pouvons éviter que ce problème ne se produise en créant deux modifications séparées, mais cela arrive généralement lorsque les développeurs ne sont pas conscients qu'ils ont des fichiers à valider pour une solution autre que celle sur laquelle ils travaillent.

Mise à jour 2019

Puisque TFS et Azure DevOps ont commencé à utiliser GIT et les Pull Requests - en utilisant des politiques de branche (sur la branche master), on peut ajouter plus d'une vérification de compilation, par exemple pour les modifications dans le chemin SolutionA\*, la compilation A peut être configurée pour être mise en file d'attente et vérifiée, et de même pour les modifications dans le chemin SolutionB\*, la compilation B peut être configurée pour être mise en file d'attente et vérifiée, et par conséquent, pour un commit ayant des modifications dans les deux chemins, les deux compilations seront mises en file d'attente pour vérification. L'attente pour l'utilisation de GIT en valait la peine.

Politiques de branche : https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation

Remarque : la documentation n'est pas mise à jour pour afficher le filtre de chemin, et un défaut est signalé sur GitHub ici https://github.com/MicrosoftDocs/vsts-docs/issues/3235. En tant que tel, le filtre est disponible dans Azure DevOps et Server.

Answer 1

@Gchaves a trouvé une solution pour ce problème, vous pouvez aller à "Modifier les définitions de build" et sur l'onglet "Espace de travail" si vous configurez votre "Dossier de contrôle de source" vers le dossier interne où se trouve SolutionA.

Par exemple, si vous avez ce système de fichiers :

1. Projects\SolutionA\SolutionA.sln
2. Projects\SolutionB\SolutionB.sln

Maintenant, si vous configurez "Dossier de contrôle de source" et "Dossier de l'agent de build" vers Projects\SolutionA, le check-in avec contrôle sera déclenché uniquement lorsque vous essayez de checkIn SolutionA, et il ne compilera que SolutionA.sln (pour que cela soit vrai, vous devez pointer uniquement vers SolutionA.sln sur l'onglet Processus -> 1. Requis -> Projets à construire)

Et ensuite vous pouvez avoir plusieurs solutions sous le même espace de travail, construire, checker et étiqueter de manière indépendante :)

Answer 2

Dans la définition de construction à l'onglet Processus, vous pouvez choisir plus d'un fichier sln à construire.

Answer 3

Une solution à ce problème consiste pour les développeurs à avoir des espaces de travail séparés définis pour les différentes solutions. S'il n'y a pas de chevauchement de code entre les solutions et que vous essayez d'empêcher un développeur de valider une solution lorsqu'il construit une autre solution, alors ils devraient utiliser des espaces de travail différents.

Si vous avez WorkspaceA pour SolutionA et WorkspaceB pour SolutionB, alors la boîte de dialogue des modifications en attente ne montrera que les modifications apportées à l'espace de travail approprié.

Comme vous le dites, vous savez que vous pouvez l'éviter en utilisant des ensembles de modifications distincts. C'est ainsi que vous pourriez "forcer" un développeur à utiliser deux ensembles de modifications distincts et éviter la situation "les développeurs ne sont pas conscients...".

Créez les espaces de travail pour eux et révoquez leur permission "Créer un espace de travail" afin qu'ils ne puissent pas en créer un qui inclut les deux domaines.

Answer 4

Je sais que tu as dit que tu "ne veux pas créer une seule définition de build pour les deux solutions", mais c'est vraiment ta seule option viable ici. Ce que je suggérerais, c'est d'avoir deux branches, une pour le développement des fonctionnalités et une pour l'intégration. Faites travailler vos développeurs dans la(les) branche(s) des fonctionnalités et utilisez des builds de validation d'intégration (ou CI) pour ces solutions. Fusionnez périodiquement les modifications de la(les) branche(s) des fonctionnalités dans une branche d'intégration qui a une seule définition de build de validation d'intégration qui construit toutes vos solutions. Cela permettra de garder les builds de votre branche d'intégration propres.