2009-07-24 6 views
14

J'ai un scénario où je veux appeler une construction TFS d'une autre, la première fait la construction et la seconde fait le staging. Cela me permettra de faire plusieurs mises en scène personnalisées pour la même solution.Comment enchaîner les builds TFS?

Je sais, je peux le retirer avec une tâche exec dans la deuxième version et appeler tfsbuild.exe pour mettre en queue une construction de la première définition de construction. Mais se demandait si quelqu'un savait d'une meilleure façon?

+1

Nous sommes passés à CC.NET - qui soutient facilement ce genre de scénario. – Sneal

+0

Je l'ai fait de nombreuses fois avec CC.NET aussi, il doit y avoir une bonne façon de faire la même chose avec TFS, je suppose! – user22242

Répondre

5

Voici comment j'accompli ce (http://sajojacob.com/2009/08/how-to-chain-tfs-builds/)

Comment la chaîne TFS Construit? Publié le août 5, 2009 par Sajo - Pas de commentaires ↓

Un de mes collègues @ gdurzi m'a récemment posé cette question. Semble assez simple pour être pris en charge hors de la boîte avec TFS non? Trop de bizarreries avec ça. Et j'ai recommandé d'utiliser la tâche MSBuild toujours fidèle pour faire un appel à TFSBuild.exe pour mettre en file d'attente une nouvelle construction du premier TFSBuild.proj avec quelque chose comme ceci

TFSBuild.exe start/queue% TFSSVR%% TEAMPROJECT%% BUILDTYPE Un problème avec l'utilisation de TFSBuild.exe est que vous ne pouvez pas passer des agents de construction en tant qu'argument de ligne de commande qui était un briseur d'affaire pour nous.

Il existe plusieurs approches que vous pouvez prendre en fonction de votre scénario particulier. Définissons le scénario ici, vous avez une définition de construction Main_Build TFS qui construit votre projet principal et vous voulez pouvoir avoir plusieurs générations de stockage exécutant le même Main_Build pour la compilation/construction, mais être personnalisé pour le déploiement basé sur qui appelle Main_Build. Très utile lorsque vous avez un produit qui s'étend à plusieurs clients avec un besoin d'actions personnalisées avant et après la construction par client. Etape 1: Créons une tâche MSBuild personnalisée à l'aide du modèle d'objet Team Foundation qui met en file d'attente une construction à l'aide de l'agent de construction par défaut associé au fichier de définition de construction.

Exemple de code pour faire la queue: QueueTFS.cs

using Microsoft.TeamFoundation.Client; 
using Microsoft.TeamFoundation.Build.Client; 

// Get the team foundation server. 
TeamFoundationServer _tfsServer = TeamFoundationServerFactory.GetServer(_tfs); 

// Get the IBuildServer 
IBuildServer buildServer = (IBuildServer)_tfsServer.GetService(typeof(IBuildServer)); 

// Get the build definition for which a build is to be queued. 
IBuildDefinition definition = buildServer.GetBuildDefinition(teamProject, buildDefinition); 

// Create a build request for the build definition. 
IBuildRequest request = definition.CreateBuildRequest(); 
request.CommandLineArguments = "Pass any custom command line args here"; // Ex: Custom Targets file 

// Queue the build. 
buildServer.QueueBuild(request, QueueOptions.None); 

Etape 2: Maintenant, copiez le QueueTFS.dll dans un nouveau dossier dans TFS où vous voulez créer la mise en scène fichier de définition de génération.

Maintenant, créons un fichier TFSBuild.proj minimal qui utilise notre nouvelle tâche MSBuild et remplace la cible EndToEndIteration. Ce sera notre définition de construction Staging qui déclenchera la construction Main_Build. Notez que vous devrez créer ce fichier TFSBuild.proj à la main et pointer simplement l'emplacement du fichier du projet de l'interface utilisateur de définition de construction vers le nouveau dossier.

Exemple de code pour une TFSBuild.proj minimale:

<?xml version="1.0" encoding="utf-8"?> 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" /> 
    <UsingTask TaskName="MyNewCustomTFSTask" AssemblyFile="QueueTFS.dll"/> 
    <Target Name="EndToEndIteration"> 
    <Message Text="About to trigger main build" Importance="high"/> 
    < MyNewCustomTFSTask TFS="http://TFSServer.com:8080/" TeamProject="TeamProject" BuildDefinition="Main_Build" TargetsFile="Custom.Target" XYZ="XYZ" /> 
    <!-- When everything is done, change the status of the task to "Succeeded" --> 
    <SetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" TestStatus="Succeeded" CompilationStatus="Succeeded"/> 
    </Target> 
</Project> 

Étape 3: Modifier votre fichier Main_Build TFSBuild.proj avec la pré-construction et les appels cibles post-construction.

<Target Name=“BeforeCompile“> 

    <CallTarget Targets=“Custom_PreBuild“/>  

    </Target> 

    <Target Name=“AfterDropBuild“ Condition=“‘$(BuildBreak)’!=’true’“>  

    <CallTarget Targets=“Custom_PostBuild“/> 

    </Target> 

Nous voulions la possibilité d'exécuter Main_Build par lui-même et, pour soutenir ce que nous ajoutons des importations conditionnelles dans notre Main_Build TFSBuild.proj d'importer un fichier cible par défaut avec des cibles vides de Custom_PreBuild et Custom_PostBuild. $ (CustomTarget) est ce que vous passeriez comme argument de ligne de commande à l'étape 1 pour request.CommandLineArguments

<Import Project="$(CustomTarget)" Condition="'$(CustomTarget)'!=''"/> 
<!--Import CustomContoso.Target if no partner is passed in—> 
<Import Project="EmptyCustom.Target" Condition="'$(CustomTarget)'==''"/> 

Étape 4: Maintenant, créez votre fichier cibles Custom.Target et EmptyCustom.Target avec des cibles Custom_PreBuild et Custom_PostBuild et vous sont fait.

J'ai ajouté le support pour la mise à jour des étapes de construction et quelques autres petites choses qui sortent du cadre de ce blog, mais cela devrait vous aider à démarrer.

7

Cela dépend de ce que vous essayez de faire.

1) Voulez-vous que le build + staging s'exécute en une seule opération? Pour que vous obteniez un rapport de construction consolidé, un fichier journal, un travail dans la file d'attente de génération du serveur, chaque étape exécutée séquentiellement par le même agent de build qui a exécuté l'étape précédente?

Si oui, alors vous êtes sur le bon chemin. Je ne voudrais pas sortir à tfsbuild.exe cependant - l'exécution d'une nouvelle construction a beaucoup de frais généraux, et je ne suis pas sûr de ce que les effets secondaires potentiels sont. Au lieu de cela, j'utiliserais la tâche <Call> pour exécuter les tâches msbuild définies dans vos scripts de transfert.

2) Souhaitez-vous que la "build build" fasse réellement la queue dans une "build de stockage" séparée? Séparez les rapports, les fichiers journaux, & points dans la file d'attente? Possibilité d'être exécuté en parallèle si vous avez plusieurs Build Builders?

Si oui, alors:

  • créer une nouvelle définition de construction (s) pour la mise en scène
  • ajouter du code à votre définition de construction d'origine que les files d'attente [un/plusieurs] des nouvelles définitions de construction en utilisant le Team Build API. Sample code.
  • enlever tout ce qui ne sont pas liées au Reconstitutions de la définition de la construction originale
  • assurez-vous que la nouvelle « mise en scène » les définitions n'ont pas de déclencheurs automatiques (intervalles de temps, les événements checkin, etc.)
+0

De préférence, l'étape 1, mais la tâche ne peut pas être utilisée comme vous le suggérez. La construction de mise en scène doit être le pilote de la construction dans ce cas. Il appelle la construction de base, puis fait son staging personnalisé. Le problème avec l'utilisation d'un fichier proj tfsbuild Minimal est que le fichier de définition TFSBuild créé via l'interface utilisateur définit toutes les propriétés du chemin en fonction de la solution choisie (comme nous l'admettons, la définition de construction staging ne doit pas reconstruire la solution). une difficulté pour obtenir les chemins configurés pour appeler le fichier TFSBuild.proj de base droit sans les coder en dur. – user22242

+0

Je ne comprends pas le problème. Pourquoi ne pas stocker vos scripts de transfert dans le même répertoire que vos scripts de construction? En fait, même cela n'est pas nécessaire - assurez-vous simplement que les chemins relatifs restent les mêmes. ///// Si cela ne vous aide pas, donnez plus de détails sur ce que vous essayez de faire. Quelles sont les choses exactes que vous attendez dans la "première construction" et la "seconde construction"? Quelles tâches ont-elles en commun, et qu'est-ce qui doit être personnalisé? –

+0

BTW, en fonction de ce que vous essayez de faire, Team Build pourrait ne pas être la bonne approche du tout. Par exemple, mes environnements de test sont configurés sur un modèle "pull" au lieu de "push". Chaque machine est abonnée au système de notification TFS. Lorsqu'un événement BuildCompletion est déclenché, un service sur la machine vérifie les différents critères configurés pour cette boîte et redéploie un environnement de test, le cas échéant. –

0

Est vous essayez de déployer votre solution dans votre environnement de transfert? Si donc une bonne méthode consiste à utiliser TFSDeployer de CodePlex qui exécuter un script PowerShell diferent basé sur la qualité de construction que vous sélectionnez ...

+1

Je peux plutôt le faire en CC au lieu de traiter la courbe d'apprentissage pour TFSDeployer pour une tâche plutôt simple comme celle-ci. Pourquoi devrait-il être si difficile de faire quelque chose d'aussi simple dans TFS que de devoir compter sur d'autres outils? Je suis surpris que peu de gens parlent même de constructions TFS chaînées – user22242

+2

La construction enchaînée ferait tomber la numérotation de ma version. J'utilise une seule build pour construire tous les "Artifacts" et ensuite j'ai besoin de le déployer vers DEV puis System Test puis QA puis Beta et enfin Live. Ceci est fait de sorte qu'il n'y a absolument aucune posabilité d'une construction contaminée (développeur checkin). S'il y a un problème, nous revenons à DEV. Ceci est fait sur chaque branche d'entité jusqu'à ce qu'il soit passé QA/UAT avant d'être fusionné en main et le Branched pour une version. :) –

1

Voici d'autres liens utiles. Cela pourrait aider les autres.

Créez une autre définition de construction et appelez les autres définitions de construction à déclencher.

http://blogs.objectsharp.com/post/2012/02/04/Create-a-Master-Build-that-calls-other-Builds.aspx

http://blog.stangroome.com/2011/09/06/queue-another-team-build-when-one-team-build-succeeds/

Arguments Passing à Builds enfant.

http://blog.stangroome.com/2014/02/19/queue-a-team-build-from-another-and-pass-parameters/

TFS Créer extension à la file une autre construction Définition

http://tfsbuildextensions.codeplex.com/

Questions connexes