Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez aussi afficher la version anglaise dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte.
Traduction
Anglais

Activités Team Foundation Build

Les activités de Team Foundation Build sont les composants sous-jacents du processus de génération de votre système Team Foundation Build. Vous pouvez utiliser ces activités pour créer un processus de génération personnalisé pour répondre aux demandes d'équipe, comme par exemple suivre la logique personnalisée ou effectuer des tâches spécialisées.

Dans la plupart des cas, la meilleure façon de créer un modèle de processus de génération personnalisé consiste à utiliser le modèle par défaut (DefaultTemplate.xaml). Ainsi, vous pouvez tirer parti des fonctionnalités généralement utiles qui ont déjà été créées lors de la personnalisation de certaines parties spécifiques pour répondre à vos besoins. Cette méthode présente un autre avantage, celui de consulter des exemples spécifiques et pratiques d'utilisation des activités décrites dans cette rubrique. Pour plus d'informations sur la création de votre modèle de processus de génération, consultez Personnaliser votre modèle de processus de génération.

Remarque importante Important

Vous devez créer un processus de génération personnalisé uniquement si vous devez répondre à des spécifications spéciales. Vous pouvez utiliser DefaultTemplate.xaml pour définir rapidement un processus de génération qui répond à de nombreuses spécifications typiques. Pour plus d'informations, consultez Utiliser le modèle par défaut pour un processus de build.

Dans cette rubrique

Pour exécuter les procédures qui utilisent des activités Team Foundation Build, vous devez disposer des autorisations suivantes avec la valeur Autoriser :

  • Modifier la définition de build

  • Extraire et archiver pour les répertoires appropriés du contrôle de version (comme le sous-répertoire BuildProcessTemplates de votre projet d'équipe)

  • Mettre les builds en file d'attente

Pour plus d'informations, consultez Référence des autorisations pour Team Foundation Server.

Vous pouvez utiliser les activités de Team Foundation Build pour effectuer les tâches suivantes :

Utilisez l'activité ExpandEnvironmentVariables pour résoudre une ou plusieurs variables d'environnement sur un serveur de builds. Les variables d'environnement sont lues dans l'agent de build si cette activité se trouve à l'intérieur d'une séquence AgentScope ; sinon, elles sont lues sur le contrôleur de build.

Conseil Conseil

Vous pouvez obtenir les bits de données utiles grâce aux variables d'environnement TF_BUILD. Par exemple, vous pouvez obtenir le répertoire des binaires, c'est-à-dire le répertoire à partir duquel le processus de génération copie les fichiers de sortie vers l'emplacement intermédiaire. Consultez Variables d'environnement Team Foundation Build.

Propriété Result de ExpandEnvironmentVariables (String)

Retourne le résultat de l'opération. Par exemple : The temp directory on machine BLDSERV3 is C:\windows\SERVIC~2\NETWOR~1\AppData\Local\Temp.

Propriétés d'argument ExpandEnvironmentVariables

  • Input (String) : Vous devez spécifier le type qui contient les variables d'environnement que vous souhaitez résoudre. Vous devez formater chaque variable d'environnement en spécifiant une propriété de MSBuild plutôt que d'utiliser la notation de symbole du pourcentage Windows. Par exemple :"The temporary directory on machine $(COMPUTERNAME) is $(TEMP)."

  • AdditionalVariables (IDictionary<String,String>) : Vous pouvez spécifier un objet IDictionary contenant toutes les variables supplémentaires (comme les clés) que vous souhaitez convertir dans leurs valeurs correspondantes.

Retour au début

Utilisez l'activité IsNotNull<T> pour vérifier si une expression Visual Basic, telle qu'une variable que vous utilisez, que vous fournissez dans la propriété Valeur (Object) n'est pas Null. Le résultat du test est retourné dans la propriété RésultatBoolean.

Utilisez l'activité IsNull<T> pour tester si une expression Visual Basic, comme une variable que vous utilisez, que vous fournissez dans la propriété Valeur (Object) est Null. Le résultat du test est retourné dans la propriété RésultatBoolean.

Chaque build a un espace de travail de contrôle de version qui est défini sur l'onglet Espace de travail de la définition de build. L'espace de travail fournit à la build un accès aux fichiers de code source et à tous les autres fichiers nécessaires du système de contrôle de version. Team Foundation Build fournit deux activités que vous pouvez utiliser pour travailler avec des fichiers dans l'espace de travail de la build : ConvertWorkspaceItemet ConvertWorkspaceItems.

Pour plus d'informations sur les espaces de travail de build, consultez Créer ou modifier une définition de build.

Conseil Conseil

Pour obtenir une aide détaillée sur le mode d'utilisation de l'activité ConvertWorkspaceItem dans un scénario classique, consultez Contrôle de l'emplacement où le système de génération copie vos fichiers binaires.

Utilisez l'activité ConvertWorkspaceItem pour convertir un chemin d'accès au serveur en chemin d'accès local sur l'agent de build ou pour convertir un chemin d'accès local sur l'agent de build en chemin d'accès au serveur.

Propriété Result de ConvertWorkspaceItem (String)

Retourne le chemin d'accès converti.

Propriétés d'argument ConvertWorkspaceItem

  • Input (String) : Vous devez fournir la valeur du chemin d'accès à convertir.

  • Espace de travail (Workspace) : Vous devez fournir une référence à l'Workspace qui contient le fichier. Dans la plupart des cas, vous devez définir cette propriété avec la variable que vous initialisez dans la propriété Result de l'activité CreateWorkspace. Si vous créez un processus de génération avec le modèle DefaultTemplate.xaml, vous devrez utiliser la variable Workspace.

  • Direction

    • Convertir un chemin d'accès au serveur en chemin d'accès local : Dans la propriété Direction, sélectionnez ServerToLocal, puis spécifiez le chemin d'accès au fichier sur le serveur dans la propriété Input (String).

      Par exemple, votre équipe peut stocker des utilitaires communs dans le répertoire suivant : $/OurTeam/BuildProcess/Util. Vous pouvez créer un processus de génération personnalisé qui exécute l'utilitaire ScanBinaries.exe après la compilation de vos fichiers binaires. Si $/OurTeam/BuildProcess/Util est mappé sur l'onglet Espace de travail de votre définition de build, vous pouvez spécifier $/OurTeam/BuildProcess/Util/ScanBinaries.exe dans la propriété Input pour obtenir le chemin d'accès local à l'utilitaire de la propriété Result (String).

    • Convertir un chemin d'accès local en chemin d'accès au serveur : Dans la propriété Direction, sélectionnez ServerToLocal, puis spécifiez le chemin d'accès local au fichier sur l'agent de build dans la propriété Input.

Utilisez l'activité ConvertWorkspaceItems pour convertir les chemins d'accès au serveur en chemins d'accès locaux sur l'agent de build ou pour convertir des chemins d'accès locaux sur l'agent de build en chemins d'accès au serveur.

Propriété Result de ConvertWorkspaceItems (IList<String>)

Retourne les valeurs converties des chemin d'accès.

Propriétés d'argument ConvertWorkspaceItems

  • Input (IEnumerable<String>) : Vous devez fournir les valeurs de chemin d'accès à convertir.

  • Espace de travail (Workspace) : Vous devez fournir une référence à l'Workspace qui contient les fichiers. Dans la plupart des cas, vous devez définir cette propriété avec la variable que vous initialisez dans la propriété Result de l'activité CreateWorkspace.

    Conseil Conseil

    Si vous créez un processus de génération avec le modèle DefaultTemplate.xaml, vous devrez utiliser la variable Workspace.

  • Direction : Sélectionnez l'une des valeurs suivantes :

    • Sélectionnez ServerToLocal si vous spécifiez une collection de valeurs de chemin d'accès au serveur dans la propriété Input et que vous souhaitez que la propriété Result retourne une liste de valeurs de chemin d'accès local.

    • Sélectionnez LocalToServer si vous spécifiez une collection de valeurs de chemin d'accès local dans la propriété Input et que vous souhaitez que la propriété Result retourne une liste de valeurs de chemin d'accès au serveur.

Vous pouvez utiliser des répertoires à l'aide de plusieurs activités dans Team Foundation Build.

Conseil Conseil

Si vous devez utiliser des répertoires qui font partie de l'espace de travail du contrôle de version de votre génération, vous devez utiliser de préférence les activités de l'espace de travail. Pour plus d'informations, consultez la rubrique Obtenir les chemins d'accès aux fichiers dans l'espace de travail.

Utilisez l'activité CreateDirectory pour créer un répertoire dont vous spécifiez le nom dans la propriété Directory (String).

Utilisez l'activité CopyDirectory pour copier de manière récursive tout le contenu d'un répertoire spécifié dans la propriété Source (String), vers un autre répertoire spécifié dans la propriété Destination (String). Le dossier que vous spécifiez dans la propriété Destination doit déjà exister. Les répertoires ou les sous-répertoires vides ne sont pas copiés.

Utilisez l'activité DeleteDirectory pour supprimer un répertoire dont vous spécifiez le nom dans la propriété Directory (String). Si le répertoire que vous supprimez contient des sous-répertoires, vous devez affecter à la propriété Recursive (Boolean) la valeur True ; sinon, la build échoue.

Utilisez l'activité GetBuildDirectory pour obtenir le chemin d'accès littéral au répertoire de travail de l'agent de build de la propriété Result (String). Vous pouvez utiliser cette activité uniquement dans une activité AgentScope.

Retour au début

Utilisez l'activité GetCommonLocalPath pour obtenir le chemin d'accès au répertoire parent commun de plus bas niveau d'un ou plusieurs dossiers locaux. Par exemple, si vous spécifiez LocalItems (IEnumerable<String>) comme suit :

{“c:\Code\Fabrikam-3\TestScrum\Main\FabrikamFiber.CallCenter”, “c:\Code\Fabrikam-3\TestScrum\Main\lib”}

Ensuite Résultat (String) retourne :

c:\Code\Fabrikam-3\TestScrum\Main

Utilisez l'activité GetCommonServerPath pour obtenir le chemin d'accès au répertoire parent commun de plus bas niveau d'un ou plusieurs dossiers locaux. Par exemple, si vous spécifiez ServerItems (IEnumerable<String>) comme suit :

{“$/TestScrum/Main/FabrikamFiber.CallCenter”, “$/TestScrum/Main/lib”}

Ensuite Résultat (String) retourne :

$/TestScrum/Main

Utilisez l'activité DownloadFiles pour télécharger un ou plusieurs fichiers. Ignorez l'activité DownloadFile.

Utilisez l'activité DownloadFiles pour télécharger un ou plusieurs fichiers du contrôle de version.

Conseil Conseil

Si les fichiers à télécharger se trouvent dans votre espace de travail de génération, vous devez y accéder à l'aide de l'activité ConvertWorkspaceItem.

Propriétés d'argument DownloadFiles

  • LocalPath (String) Vous devez spécifier une valeur :

    • Si vous téléchargez un seul fichier, spécifiez le chemin d'accès local et le nom que vous souhaitez attribuer à la copie locale du fichier que vous téléchargez ; par exemple "c:\Docs\readme.txt".

    • Si vous téléchargez plusieurs fichiers, spécifiez le chemin d'accès local au dossier dans lequel vous souhaitez télécharger les fichiers ; par exemple "c:\Docs\".

  • ServerPath (String) Vous devez spécifier une valeur :

    • Si vous téléchargez un seul fichier, spécifiez le chemin d'accès au serveur et le nom du fichier que vous téléchargez ; par exemple "$/Docs/readme.txt".

    • Si vous téléchargez plusieurs fichiers, spécifiez le chemin d'accès du serveur au répertoire qui contient les fichiers que vous souhaitez télécharger ; par exemple "$/Docs/".

  • Recursion (RecursionType) :

    • OneLevel : Télécharge le ou les fichiers dans le répertoire que vous spécifiez dans la propriété ServerPath.

    • Full : Télécharge les fichiers dans le répertoire que vous spécifiez dans la propriété ServerPath et tous les fichiers dans les sous-répertoires.

  • Version (String) : Vous pouvez définir une spécification de version (versionspec). Pour télécharger la version actuelle, laissez à cette propriété la valeur Microsoft.TeamFoundation.VersionControl.Client.VersionSpec.Latest.DisplayString. Pour plus d'informations sur ces spécifications de versions (versionspecs), consultez Syntaxe de ligne de commande.

  • DeletionID (Int32) : Vous devez spécifier cette propriété uniquement si vous téléchargez un fichier qui a été supprimé du contrôle de version. Vous pouvez obtenir cette valeur de manière interactive en tapant tf dir /deleted à l'invite de commandes. (Pour plus d'informations, consultez Dir Command). Toutefois, Team Foundation Build ne fournit pas d'activité intégrée pour obtenir un ID de suppression DeletionID. Pour utiliser cette propriété, vous devez obtenir ou créer une activité personnalisée qui fournit cette fonctionnalité.

Retour au début

Ignorez l'activité DownloadFile. L'activité DownloadFiles est le moyen le plus simple de télécharger un ou plusieurs fichiers.

Utilisez l'activité FindMatchingFiles pour rechercher des fichiers. Spécifiez les critères de recherche dans la propriété MatchPattern (String). Dans cette propriété, vous pouvez spécifier un argument qui inclut les éléments suivants :

  • Syntaxe qui est prise en charge par l'argument searchPattern de la méthode DirectoryGetFiles(String, String).

  • ** pour spécifier une recherche récursive. Par exemple :

    • Pour rechercher dans le répertoire source les fichiers texte, vous pouvez spécifier une chaîne qui ressemble à la valeur suivante de la propriété MatchPattern : String.Format("{0}\**\*.txt", SourcesDirectory).

    • Pour rechercher dans le répertoire source des fichiers texte dans un ou plusieurs sous-répertoires appelés txtfiles, vous pouvez spécifier une chaîne qui ressemble à la valeur suivante de la propriété MatchPattern : String.Format("{0}\**\txtfiles\*.txt", SourcesDirectory).

Vous collectez les résultats de l'opération dans la propriété Result (IEnumerable<String>).

Utilisez l'activité de WriteCustomSummaryInformation pour écrire un message dans le résumé de la build, qui s'affiche pour les utilisateurs dans la fenêtre des résultats de la build.

Propriétés d'argument de WriteCustomSummaryInformation

  • Message (String) : vous devez spécifier le message à afficher dans le résumé de la build.

    Vous pouvez inclure des liens hypertexte dans le message à l'aide de l'une des syntaxes suivantes :

    [link text](url)
    [link text] (url)
    

    Par exemple :

    For the latest operation status, see [Fabrikam Fiber Ops] (http://intranet.fabrikam.com/ops/status).
    
  • SectionDisplayName (String) : vous devez spécifier le nom de la section dans laquelle vous souhaitez afficher le message. Si plusieurs instances de WriteCustomSummaryInformation avec la même valeur SectionKey spécifient différentes valeurs SectionDisplayName, le système utilise SectionDisplayName de la première instance du modèle de processus de génération.

  • SectionKey (String) : vous devez spécifier un identificateur pour le nom de la section dans laquelle vous souhaitez afficher le message. La valeur que vous spécifiez doit être conforme aux règles décrites dans NameProperty.

    Par exemple, si vous implémentez deux instances de WriteCustomSummaryInformation avec une valeur SectionKey de “MySection”, lorsque votre build est traitée, les deux messages s'affichent dans la même section du résumé de la build.

  • SectionPriority (Int32) : vous pouvez spécifier la priorité de la section, qui détermine ensuite la position relative de la section dans le résumé de la build. Plus la valeur est faible, plus la section apparaîtra en haut du résumé. Si plusieurs instances de WriteCustomSummaryInformation avec la même valeur SectionKey spécifient différentes valeurs SectionPriority, le système utilise la valeur SectionPriority de la première instance du modèle de processus de génération.

Retour au début

Utilisez l'activité WriteBuildMessage pour écrire un message d'information dans le journal de génération. Vous devez spécifier le message dans la propriété Message (String). Vous pouvez également indiquer l'importance du message en modifiant la valeur de la propriété Importance (BuildMessageImportance).

Conseil Conseil
  • Les utilisateurs de votre processus de génération peuvent compter sur le filtrage des commentaires pour réduire la surcharge d'informations par rapport au résultat affiché et aux données stockées dans l'entrepôt. Vous pouvez rendre ce filtrage plus efficace en suivant une méthode réfléchie et cohérente pour définir la propriété Importance de vos messages de génération. Pour plus d'informations, consultez Gérer des informations sur les builds et contrôler les commentaires.

  • Si vous utilisez les paramètres par défaut, votre message ne sera pas consigné dans le journal de génération. Pour résoudre ce problème, effectuez l'une des étapes suivantes :

    • Affectez à la propriété WriteBuildMessageImportance la valeur Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High.

    • Sous l'onglet Processus de la définition de build, affectez au paramètre du processus Commentaires de journalisation la valeur Detailed ou Diagnostic.

Utilisez l'activité WriteBuildWarning pour consigner un message d'avertissement dans le journal de génération. Les messages d'avertissement s'affichent avec un point d'exclamation jaune dans la fenêtre d'affichage des résultats de génération. Vous devez spécifier le message dans la propriété Message (String).

Les avertissements de génération sont consignés uniquement lorsque votre équipe affecte au paramètre des commentaires la valeur minimum ou plus. Pour plus d'informations, consultez Gérer des informations sur les builds et contrôler les commentaires.

Utilisez l'activité WriteBuildError pour écrire un message d'erreur de build dans le journal de build. Les erreurs apparaissent avec un point d'exclamation rouge dans la fenêtre d'affichage des résultats de génération. Lorsqu'une erreur est consignée dans le journal de génération, la build est classée comme Partially Succeeded au mieux. Vous devez spécifier le message dans la propriété Message (String).

Les erreurs sont toujours enregistrées, indépendamment du paramètre de commentaires. Pour plus d'informations, consultez Gérer des informations sur les builds et contrôler les commentaires.

Utilisez l'activité WriteBuildTestError pour écrire un message d'erreur de test dans le journal de build. Les erreurs apparaissent avec un point d'exclamation rouge dans la fenêtre d'affichage des résultats de génération. Lorsqu'une erreur est consignée dans le journal de génération, la build est classée comme Partially Succeeded au mieux. Vous devez spécifier le message dans la propriété Message (String).

Les erreurs sont toujours enregistrées, indépendamment du paramètre de commentaires. Pour plus d'informations, consultez Gérer des informations sur les builds et contrôler les commentaires.

Utilisez l'activité WriteBuildInformation<T> pour consigner un objet dans le journal de génération. Lorsqu'un utilisateur affiche le journal dans la fenêtre d'affichage des résultats de génération, l'objet est restitué en utilisant la réflexion.

Propriétés d'argument WriteBuildInformation<T>

  • Value (Object) : Vous devez spécifier l'objet à consigner dans le journal de génération. Pour que votre objet soit affiché dans la fenêtre d'affichage des résultats de génération, l'objet doit implémenter IBuildInformationNode et affecter l'une des valeurs suivantes InformationTypes à Type :

    • ActivityProperties

    • ActivityTracking

    • AgentScopeActivityTracking

    • BuildError

    • BuildMessage

    • BuildProject

    • BuildStep

    • BuildWarning

    • ExternalLink

    • OpenedWorkItem

  • ParentToBuildDetail : Vous pouvez spécifier False pour que le parent de cet objet devienne le parent de cette activité, ou vous pouvez spécifier True pour que l'objet IBuildDetail devienne le parent.

    Cette propriété a pour effet de définir le mode d'affichage des informations dans la fenêtre d'affichage des résultats de génération. Si vous spécifiez False, les informations sont mises en retrait et alignées avec le résultat des autres activités qui arrivent avant et après l'activité WriteBuildInformation<T> et qui sont au même niveau. Si vous spécifiez True, les informations ne sont pas mises en retrait.

Retour au début

Vous pouvez enregistrer des métadonnées relatives à la build dans l'entrepôt de données :

Conseil Conseil

Si ces activités ne prennent pas en charge les métadonnées que vous souhaitez écrire, vous pouvez utiliser l'activité GetBuildDetail pour obtenir une référence à l'objet IBuildDetail, puis assigner les données directement à l'objet à l'aide de cette référence.

Utilisez l'activité UpdateBuildNumber pour définir le numéro de build (ou le nom) de la build. Cette activité effectue les étapes suivantes :

  1. Crée un numéro de build en fonction d'une expression qui détermine le format du numéro de build. Votre processus de génération accepte généralement cette expression à partir d'un argument de flux de travail qui est fourni par un paramètre sous l'onglet Processus d'une définition de build.

  2. Définit le numéro de build (ou le nom) de la build en écrivant la valeur résultante dans la propriété BuildNumber.

Propriété Result de UpdateBuildNumber (String)

Result : Retourne la nouvelle valeur BuildNumber.

Propriétés UpdateBuildNumber

Retour au début

Utilisez SetBuildProperties pour écrire des points de données clés dans l'objet IBuildDetail qui gère le stockage des données sur chaque génération dans l'entrepôt de données. La majorité de ces données s'affiche pour l'utilisateur dans la fenêtre d'affichage des résultats de génération.

Propriétés SetBuildProperties

  • PropertiesToSet : Vous devez cocher les cases correspondant aux noms des propriétés que vous souhaitez définir.

  • BuildNumber (String) : Vous pouvez définir l'ID BuildNumber de la build que vous pouvez considérer comme nom de la build.

    Conseil Conseil

    Si vous souhaitez définir cette valeur en fonction des paramètres spécifiés par l'utilisateur sous l'onglet Processus de la définition de build, vous devrez sans doute utiliser l'activité UpdateBuildNumber à la place de cette propriété.

  • CompilationStatus (BuildPhaseStatus) : Vous pouvez définir l'état de compilation (CompilationStatus). (L'activité MSBuild définit également cette valeur automatiquement.)

  • DropLocation (String) : Vous pouvez enregistrer l'emplacement cible dans la propriété DropLocation.

    Remarque Remarque

    Si vous définissez cette propriété, vous ne créez pas réellement l'emplacement cible. Utilisez plutôt cette propriété pour stocker, dans l'entrepôt de données, l'emplacement du dossier de dépôt, que vous créez en général à l'aide de l'activité CreateDirectory.

  • KeepForever (Boolean) : Vous pouvez affecter à la propriété KeepForever la valeur True si vous souhaitez ignorer les paramètres de l'onglet Stratégie de rétention de la définition de build et conserver la build terminée indéfiniment.

  • LabelName (String) : Vous pouvez définir la propriété LabelName pour enregistrer l'étiquette que vous avez utilisée pour marquer cette build dans les fichiers de code source du contrôle de version. En général, vous définissez cette propriété pour qu'elle corresponde à la valeur dans la propriété Nom de l'activité LabelWorkspace.

    Remarque importante Important

    Avec Team Foundation Build, ces données doivent associer l'ensemble de modifications et les éléments de travail aux générations. Si vous ne fournissez pas ces données, l'activité AssociateChangesetsAndWorkItems échoue.

  • LogLocation (String) : Vous pouvez utiliser la propriété LogLocation pour enregistrer le chemin d'accès au fichier UNC dans le dossier où votre processus de génération enregistre le fichier journal.

    Remarque Remarque

    Vous n'aurez probablement pas besoin d'utiliser cette propriété dans votre processus de génération personnalisé. Cette propriété est principalement destinée à une utilisation par le fichier UpgradeTemplate.xaml pour prendre en charge les processus de génération hérités.

  • Quality (String) : Vous pouvez enregistrer la qualité de la build dans la propriété Quality.

  • SourceGetVersion (String) : Vous pouvez utiliser la propriété SourceGetVersion pour stocker la spécification de version pour laquelle les sources sont extraites de cette génération.

  • Status (BuildStatus) : Vous pouvez enregistrer l'état global de la build dans la propriété Status. Par exemple, vous pouvez utiliser cette propriété pour indiquer si la build s'est déroulée avec succès ou si elle a échoué.

  • TestStatus (BuildPhaseStatus) : Vous utilisez la propriété TestStatus pour enregistrer l'état global des tests qui ont été exécutés sur cette génération. Par exemple, vous pouvez utiliser cette propriété pour indiquer si les tests que vous avez exécutés sur cette génération se sont déroulés avec succès ou s'ils ont échoué.

Retour au début

Vous pouvez utiliser les activités Team Foundation Build pour contrôler le processus de génération de différentes façons :

Utilisez l'activité AgentScope pour encadrer les parties de votre processus de génération que vous souhaitez exécuter sur l'agent de build.

Propriétés d'argument AgentScope

  • Sélection d'agent

    • MaxWaitTime (TimeSpan) : Vous pouvez spécifier le délai maximum durant lequel le processus de génération attend qu'un agent de build devienne disponible. Vous pouvez entrer une valeur au format hh:mm:ss. Par exemple, la build échoue avec une erreur de délai d'expiration si vous spécifiez une valeur de 01:30:45 et que la build n'a pas été assignée à un agent de build après 1 heure, 30 minutes et 45 secondes. Si vous souhaitez accorder au contrôleur de build un temps illimité pour rechercher un agent de build pour traiter cette définition de build, spécifiez une valeur de 00:00:00.

      Remarque importante Important

      Vous pouvez éviter de sauvegarder votre file d'attente de build en spécifiant une valeur différente de zéro raisonnable dans la propriété MaxWaitTime

    • ReservationSpec (AgentReservationSpec) : Vous pouvez limiter le type d'agent de build qui doit traiter les actions que cette activité contient. Par exemple, vous pouvez indiquer que seuls les agents de build associés à une balise sont utilisés pour traiter les activités à l'intérieur de l'activité AgentScope.

  • Exécution

    • MaxExecutionTime (TimeSpan) : Vous pouvez définir la durée d'exécution maximum autorisée pour cette activité AgentScope. Vous pouvez entrer une valeur au format hh:mm:ss. Par exemple, la build échoue avec une erreur de délai d'expiration si vous spécifiez une valeur de 04:30:15 et que l'agent de build n'a pas terminé son travail après 4 heures, 30 minutes et 15 secondes. Si vous souhaitez accorder à l'agent de build un temps illimité pour traiter la build, spécifiez une valeur de 00:00:00.

      Conseil Conseil

      Vous pouvez éviter de sauvegarder votre file d'attente de build en spécifiant une valeur différente de zéro raisonnable dans la propriété MaxExecutionTime

  • Portée

    • DataToIgnore : Ignorez cette propriété.

Retour au début

Utilisez l'activité SharedResourceScope pour implémenter une structure mutex nommée (exclusion mutuelle) qui encapsule le segment de votre processus de génération pour le rendre « thread-safe. »

Une utilisation courante de cette activité consiste à encadrer les parties d'un processus de génération qui doit accéder à une ressource partagée devant être accessible par un seul processus à la fois. Par exemple, vous pouvez utiliser vos générations pour écrire, dans l'ordre séquentiel, dans un seul fichier texte sur un partage de fichiers. Pour garantir que ce genre de processus fonctionne correctement, vous devez l'implémenter à l'intérieur d'une activité SharedResourceScope.

Vous pouvez rechercher un autre exemple dans le modèle DefaultTemplate.xaml, dans lequel l'appel de l'activité PublishSymbols est intégrée dans une activité SharedResourceScope :

  1. Séquence (Sequence) >

  2. Exécuter sur l'agent (AgentScope) >

  3. Essayer de compiler, tester et associer des ensembles de modifications et des éléments de travail (TryCatch [Try]) >

  4. Séquence (Sequence) >

  5. Obtenir des tests impactés, indexer les sources et publier les symboles (Parallel) >

  6. Si SourceAndSymbolServerSettings.IndexSources ou SourceAndSymbolServerSettings.HasSymbolStorePath (If [Then]) >

  7. Indexer les sources et publier des symboles pour les générations déclenchées (InvokeForReason) >

  8. Si SourceAndSymbolServerSettings.HasSymbolStorePath (If [Then]) >

  9. Essayer de publier des symboles (TryCatch [Try]) >

  10. Synchroniser l'accès au magasin de symboles (SharedResourceScope) >

  11. Publier des symboles (PublishSymbols)

Propriétés d'argument SharedResourceScope

  • ResourceName (String) : Vous devez spécifier une valeur. Toutes les instances des activités SharedResourceScope sont exécutées individuellement si elles partagent la même valeur ResourceName dans votre collection de projets d'équipe (même si elles se trouvent dans des différents modèles de définition de build).

  • MaxExecutionTime (TimeSpan) : Vous pouvez définir la durée d'exécution maximum autorisée pour cette activité SharedResourceScope. Vous pouvez entrer une valeur au format hh:mm:ss. Par exemple, la build échoue avec une erreur de temporisation si vous spécifiez une valeur 04:30:15 et que l'activité SharedResourceScope n'est pas terminée après 4 heures, 3 minutes et 15 secondes. Spécifiez la valeur 00:00:00 si vous souhaitez accorder une durée illimitée pour traiter l'activité SharedResourceScope.

    Conseil Conseil

    Vous pouvez éviter de sauvegarder votre file d'attente de build en spécifiant une valeur différente de zéro raisonnable dans la propriété MaxExecutionTime

  • MaxWaitTime (TimeSpan) : Vous pouvez spécifier le délai maximum durant lequel le processus de génération attend dans la file d'attente de traiter l'activité SharedResourceScope. Vous pouvez entrer une valeur au format hh:mm:ss. Par exemple, la build échoue avec une erreur de temporisation si vous spécifiez une valeur 01:30:45 et que l'activité SharedResourceScope n'est pas traitée après 1 heure, 30 minutes et 45 secondes. Spécifiez la valeur 00:00:00 si vous souhaitez accorder au processus de génération une durée d'attente illimitée dans la file d'attente.

    Conseil Conseil

    Vous pouvez éviter de sauvegarder votre file d'attente de build en spécifiant une valeur différente de zéro raisonnable dans la propriété MaxWaitTime

Retour au début

Utilisez l'activité InvokeForReason pour encadrer un segment de votre processus de génération à exécuter uniquement dans les générations exécutées pour une raison particulière. Les raisons de la build sont généralement définies par le déclencheur que l'utilisateur sélectionne sous l'onglet Déclencheur de la définition de build. Vous pouvez spécifier, dans la propriété Raison, une ou plusieurs valeurs de raison que vous souhaitez autoriser. Pour plus d'informations, consultez Spécifier les raisons et les déclencheurs de build.

Retour au début

Vous pouvez utiliser les activités Team Foundation Build pour compiler des fichiers binaires, exécuter des tests et effectuer d'autres tâches :

Utilisez l'activité MSBuild pour compiler des fichiers binaires, effectuer l'analyse du code et tirer parti de toute autre fonctionnalité fournie par MSBuild.

Résultat MSBuild

Aucune propriété de cette activité ne retourne de résultat. Toutefois, la valeur Failed est affectée à cette activité CompilationStatus si des erreurs de compilation sont consignées.

Propriétés d'argument MSBuild

  • AdditionalVCOverrides (String) : Si vous affectez à GenerateVsPropsFile la valeur True, le contenu de cette propriété est intégré dans le fichier .vsprops généré.

  • CommandLineArguments (String) : Vous pouvez spécifier des arguments de ligne de commande que vous souhaitez passer à MSBuild.

  • Configuration (String) : Vous pouvez spécifier la configuration à générer. Par exemple : “debug” ou “release”.

  • GenerateVSPropsFile (Boolean): Si cette propriété a la valeur True, MSBuild génère un fichier .vsprops standard à passer aux projets C++. Ce fichier inclut le répertoire de sortie pour les projets C++ et tout élément que vous spécifiez dans la propriété AdditionalVCOverrides.

  • LogFile (String) : Vous pouvez spécifier le nom du fichier journal que MSBuild doit créer.

  • LogFileDropLocation (String) : Vous pouvez spécifier le chemin d'accès UNC complet au répertoire dans lequel vous souhaitez que MSBuild insère le fichier journal.

  • MaxProcesses (Int32) : Vous pouvez spécifier le nombre maximum de processus que MSBuild crée.

  • OutDir (String) Vous pouvez spécifier le répertoire dans lequel MSBuild dépose les fichiers binaires compilés. Pour plus d'informations, consultez Contrôle de l'emplacement où le système de génération copie vos fichiers binaires.

  • Platform (String) : Vous pouvez spécifier la plateforme de génération de MSBuild. Par exemple : “Any CPU”, “x86” ou “x64”.

  • Project (String) : Vous pouvez spécifier la solution ou le projet de code que crée MSBuild.

  • ResponseFile (String) : Vous pouvez spécifier le fichier réponse que MSBuild utilise.

  • RunCodeAnalysis (CodeAnalysisOption) : Vous pouvez indiquer si l'analyse du code doit toujours être exécutée, ne doit jamais être exécutée ou doit être exécutée en fonction des paramètres du projet.

  • Targets (IEnumerable<String>) : Vous pouvez spécifier des cibles à générer.

  • TargetsNotLogged (IEnumerable<String>) : Vous pouvez spécifier les cibles pour lesquelles les événements ProjectStarted ne doivent pas être consignés.

  • ToolPath (String) : Vous pouvez spécifier le chemin d'accès à l'outil.

  • ToolPlatform (ToolPlatform) : Vous pouvez spécifier la plateforme de l'outil. Spécifiez Microsoft.TeamFoundation.Build.Workflow.Activities.ToolPlatform.Auto pour détecter la plateforme en fonction du système d'exploitation actuel.

  • Verbosity (BuildVerbosity) : Vous pouvez spécifier les commentaires du journal que génère MSBuild.

Pour plus d'informations sur les nombreuses options de MSBuild qui affectent les propriétés de MSBuild, consultez Référence de la ligne de commande MSBuild.

Retour au début

Vous pouvez exécuter des tests à l'aide de l'activité RunTests ou de l'activité MSTest.

Utilisez l'activité RunTests pour utiliser Agile Test Runner pour exécuter des tests. Si votre build compile et teste des binaires avec des plateformes incompatibles, vous devez exécuter cette activité séparément pour chaque assembly de chaque plateforme.

Pour plus d'informations, consultez Exécuter des tests dans votre processus de génération.

Propriétés principales de RunTests

  • TestSources (IEnumerable<String>) : vous devez spécifier une liste des fichiers d'assembly contenant les tests à exécuter.

  • ExecutionPlatform (ExecutionPlatformType) Vous pouvez spécifier la plateforme des fichiers binaires que vous souhaitez tester. Pour plus d'informations, consultez Agile Test Runner.

  • ExecutionTimeout (Int32) : vous pouvez spécifier la quantité maximale de temps pendant laquelle le processus de génération peut attendre avant la fin des tests. Spécifiez une valeur 0 si vous souhaitez donner à l'activité RunTests un temps illimité pour l'exécution des tests.

  • KeepAlive (Boolean) : vous pouvez définir cette propriété avec True si vous souhaitez que le processus Agile Test Runner continuer à s'exécuter sur l'agent de build après que l'activité RunTests est terminée.

  • RunSettings (String) : non documenté.

  • TestCaseFilter (String) : vous pouvez utiliser cette propriété pour exécuter un sous-ensemble de vos cas de test. Pour plus d'informations, consultez Spécifier les critères des tests exécutés par Visual Studio Test Runner.

  • UpdateFrequency (Int32) : non documenté.

  • UpdateFrequencyTimeout (Int32) : non documenté.

Propriétés de publication de RunTests

Vous pouvez utiliser les propriétés suivantes pour publier les résultats des tests dans la collection de projets d'équipe :

  • PublishResults (Boolean) : vous devez affecter à cette propriété la valeur True si vous souhaitez publier les résultats des tests.

  • Flavor (String) : Vous pouvez spécifier la version de la build pour laquelle vous avez exécuté les tests dont vous souhaitez publier les résultats.

  • Platform (String) : Vous pouvez spécifier la plateforme de la build pour laquelle vous avez exécuté les tests dont vous souhaitez publier les résultats.

  • RunName (String) : vous pouvez spécifier le nom de la série de tests. Les clients de votre processus de build ne verront pas ce nom dans le résumé de la fenêtre des résultats de la build. Si vous ne fournissez pas de nom, le système en génère automatiquement un.

Délégués

  • OnTestCompleted : non documenté.

  • OnTestRunCompleted : non documenté.

Retour au début

Utilisez cette activité pour exécuter des tests à l'aide de MSTest.exe.

Propriétés principales de MSTest

Pour commencer, déterminez le mode d'exécution des tests, puis spécifiez les valeurs des propriétés appropriées.

  • Pour exécuter des tests dans des conteneurs de test (méthode recommandée), utilisez les propriétés suivantes :

    • TestContainers (IEnumerable<String>) : Vous devez spécifier les conteneurs des tests à exécuter. Cette propriété est l'équivalent de l'option /testcontainer de la commande MSTest.exe. Pour plus d'informations, consultez Options de ligne de commande MSTest.exe (/testcontainer).

    • SearchPathRoot (String) : Vous pouvez spécifier la racine du chemin d'accès au répertoire dans lequel vous pouvez rechercher les conteneurs de test et leurs dépendances. Si vous ne spécifiez pas de valeur, l'activité MSTest tente de rechercher les fichiers dans des emplacements standard.

    • TestSettings (String) : Vous pouvez spécifier un fichier de configuration de série de tests à utiliser. Cette propriété est l'équivalent de l'option /testsettings de la commande MSTest.exe. Pour plus d'informations, consultez Options de ligne de commande MSTest.exe (/testsettings).

  • Pour exécuter des tests dans les listes de tests, utilisez les propriétés suivantes :

Propriétés de filtrage MSTest

Vous pouvez utiliser les propriétés suivantes pour filtrer les tests à exécuter :

  • Category (String) : Vous pouvez filtrer les tests en fonction de leurs catégories de test. Cette propriété est l'équivalent de l'option /category de la commande MSTest.exe. Pour plus d'informations, consultez la rubrique sur les options de ligne de commande MSTest.exe (/category) et Définition de catégories de test pour regrouper vos tests.

  • MaxPriority (Int32) : Vous pouvez spécifier la priorité maximum des tests à exécuter. Seuls les tests dont la priorité est inférieure ou égale à cette valeur seront exécutés. Vous devez spécifier un entier positif qui soit supérieur ou égal à la propriété MinPriority, ou vous devez spécifier -1 si vous ne souhaitez pas définir un niveau de priorité maximum.

    Conseil Conseil

    Si vous avez assigné des priorités à vos tests, les propriétés MinPriority et MaxPriority peuvent représenter un moyen important pour vous aider à définir un équilibre entre des tests approfondis et des générations plus rapides.

  • MinPriority (Int32) : Vous pouvez spécifier la priorité minimum des tests à exécuter.. Seuls les tests dont la priorité est supérieure ou égale à cette valeur seront exécutés. Vous devez spécifier un entier positif qui soit inférieur ou égal à la propriété MaxPriority, ou vous devez spécifier -1 si vous ne souhaitez pas définir un niveau de priorité minimum.

  • TestNames (IEnumerable<String>) : Vous pouvez spécifier le noms des tests à exécuter. Cette propriété est l'équivalent de l'option /test de la commande MSTest.exe. Pour plus d'informations, consultez Options de ligne de commande MSTest.exe (/test).

Propriétés de publication MSTest

Vous pouvez utiliser les propriétés suivantes pour publier les résultats des tests dans la collection de projets d'équipe :

  • Publish (Boolean) : Vous devez affecter à cette propriété la valeur True si vous souhaitez publier les résultats des tests.

  • Flavor (String) : Vous pouvez spécifier la version de la build pour laquelle vous avez exécuté les tests dont vous souhaitez publier les résultats. Cette propriété est l'équivalent de l'option /flavor de la commande MSTest.exe. Pour plus d'informations, consultez Options de ligne de commande pour la publication des résultats de tests.

  • Platform (String) : Vous pouvez spécifier la plateforme de la build pour laquelle vous avez exécuté les tests dont vous souhaitez publier les résultats. Cette propriété est l'équivalent de l'option /platform de la commande MSTest.exe. Pour plus d'informations, consultez Options de ligne de commande pour la publication des résultats de tests.

  • TestConfigId (Int32) : Vous pouvez spécifier l'ID d'une configuration de gestion de test existante à associer à la série de tests dont vous souhaitez publier les résultats. Cette propriété est l'équivalent de l'option /testconfigid de la commande MSTest.exe. Pour plus d'informations, exécutez MSTest /? à l'invite de commandes de Visual Studio.

  • TestConfigName (String) : Vous pouvez spécifier le nom d'une configuration de gestion de test existante à associer à la série de tests dont vous souhaitez publier les résultats. Cette propriété est l'équivalent de l'option /testconfigname de la commande MSTest.exe. Pour plus d'informations, exécutez MSTest /? à l'invite de commandes de Visual Studio.

Autres propriétés MSTest

  • CommandLineArguments (String) : Pour plus d'informations sur les options de ligne de commande supplémentaires que vous pouvez spécifier, consultez Options de ligne de commande MSTest.exe.

  • PathToResultsFilesRoot (String) : Vous pouvez spécifier la racine du chemin d'accès au répertoire sur l'agent de build où MSTest.exe enregistre les fichiers de résultats (fichiers .trx).

  • ToolPath (String) : Vous pouvez spécifier le chemin d'accès au répertoire qui contient la version de MSTest.exe à exécuter. Si vous ne spécifiez pas de chemin d'accès, Team Foundation Build détermine automatiquement le chemin d'accès en fonction des données dans vos listes ou conteneurs de tests.

Retour au début

Utilisez l'activité GetImpactedTests pour identifier les modifications de code de la build en cours et pour générer une liste de tests affectés par ces modifications. L'activité enregistre la liste des tests affectés dans l'entrepôt de données pour aider les membres de l'équipe des tests à déterminer les tests à exécuter à l'issue de cette génération. Pour plus d'informations sur la manière dont votre équipe peut utiliser ces données, consultez Quels tests doivent être exécutés depuis une version antérieure ?.

Remarque Remarque

Cette activité n'a aucun effet dans les builds d'archivage contrôlé ou les builds privées.

Conditions requises

L'activité GetImpactedTests peut fonctionner uniquement lorsque les conditions suivantes sont remplies :

  • L'activité MSTest a été exécutée avec un fichier de paramètres de test (spécifié dans la propriété TestSettings) qui collecte les données d'impact des tests. Vous pouvez utiliser le fichier Traceandtestimpact.testsettings qui est généré automatiquement, ou vous pouvez utiliser un autre fichier de paramètres de test dans lequel la case à cocher Impact de test est activée. Pour plus d'informations, consultez Comment : collecter des données pour vérifier quels tests doivent être exécutés après les modifications de code.

  • L'activité GetImpactedTests a permis d'identifier la build précédente. Pour plus d'informations, consultez la section suivante.

Comment l'activité GetImpactedTests identifie la build précédente

L'activité GetImpactedTests produit ses résultats en comparant la build en cours avec la build précédente. L'activité identifie la build précédente à l'aide du processus suivant :

  1. Si vous spécifiez la propriété BaselineBuildDropLocation, la build qui a généré ces fichiers binaires est identifiée comme génération précédente.

  2. Si vous ne spécifiez pas la propriété BaselineBuildDropLocation, l'activité identifie la build précédente en recherchant dans l'entrepôt de données la build la plus récente qui correspond à tous les critères suivants :

    • La build a la même propriété BuildDefinitionUri que celle de la build en cours.

    • La propriété Status de la build est Succeeded ou PartiallySucceeded.

    • La build a une propriété DropLocation.

    • La build n'est pas une build d'archivage contrôlé ou une build privée.

Propriétés de résultat GetImpactedTests

  • CodeChanges (CodeChangeList) : Retourne une liste des modifications apportées à chaque méthode dans votre code entre cette génération et la build précédente. Les méthodes sont analysées au niveau du langage MSIL (Microsoft Intermediate Langage).

  • ImpactedTests (TestList) : Retourne une liste des tests qui ont été affectés par les modifications de code entre la build précédente et cette génération.

Propriétés d'argument GetImpactedTests

  • Divers

    • Build : Vous devez fournir l'objet IBuildDetail de la build. Vous pouvez utiliser l'activité GetBuildDetail pour obtenir une référence à cet objet.

  • Divers

    • Assemblies (IEnumerable<String>) : Vous devez spécifier une liste d'assemblys que vous souhaitez que cette activité examine. En général, vous avez créé ces assemblys dans cette génération.

    • AssociatedChangesets (IList<Changeset>) : Vous pouvez spécifier les ensembles de modifications que vous souhaitez associer aux résultats d'impact de test. En général, vous spécifiez les ensembles de modifications que vous générez. Vous pouvez obtenir une référence à ces ensembles de modifications dans l'activité AssociateChangesetsAndWorkItems.

    • BinariesRoot (String) : Vous devez spécifier le chemin d'accès aux fichiers binaires dont dépendent vos assemblys. Vous pouvez obtenir cette valeur à l'aide de l'activité GetBuildDirectory.

    • Espace de travail (Workspace) : Vous devez fournir une référence à l'espace de travail de votre génération. Vous pouvez obtenir cette référence à partir de la propriété Result de l'activité CreateWorkspace.

    • BaselineBuildDropLocation (String) : Vous pouvez spécifier le chemin d'accès au dossier de dépôt qui contient la build terminée que l'activité GetImpactedTests compare à la build en cours. Si vous ne spécifiez pas cette propriété, l'activité tente de rechercher dans le système de génération la build précédente. Pour plus d'informations, consultez la rubrique « Comment l'activité GetImpactedTests identifie la build précédente » décrite précédemment dans cette section.

Retour au début

Utilisez l'activité InvokeProcess pour démarrer un processus (exécuter un programme) sur le serveur de builds. Cette activité est essentiellement un wrapper sur Start.

Propriété Result de InvokeProcess (Int32)

Retourne ExitCode du processus.

Propriétés d'argument InvokeProcess

  • FileName (String) : Vous devez spécifier la propriété FileName du processus à démarrer (le programme que vous souhaitez exécuter). Par exemple : %ProgramFiles%\ContosoBuildUtils\MarkBins.exe.

  • Arguments (String) : Vous pouvez spécifier les arguments de ligne de commande (Arguments) à passer au processus.

  • EnvironmentVariables (IDictionary<String,String>) : Vous pouvez spécifier des variables d'environnement supplémentaires (EnvironmentVariables) et leurs valeurs.

  • OutputEncoding (Encoding) : Vous pouvez spécifier l'encodage utilisé pour lire les flux de sortie (StandardOutputEncoding) et d'erreurs (RedirectStandardError). Dans de nombreux cas, la valeur par défaut est la meilleure valeur pour cette propriété :

    System.Text.Encoding.GetEncoding(System.Globalization.CultureInfo.InstalledUICulture.TextInfo.OEMCodePage)
    
  • WorkingDirectory (String) : Vous pouvez spécifier le répertoire de travail (WorkingDirectory) dans lequel vous souhaitez exécuter le processus.

    Par exemple, vous pouvez exécuter votre utilitaire MarkBins.exe sur vos fichiers binaires compilés. Pour limiter la portée d'exécution de l'utilitaire, vous pouvez appeler l'activité GetBuildDirectory et placer le résultat dans cette propriété.

Pour afficher la sortie standard et la sortie d'erreur de votre processus

  1. Dans l'activité InvokeProcess, double-cliquez sur Double-cliquer pour afficher.

  2. Faites glisser une activité WriteBuildMessage de la boîte à outils pour que l'activité s'affiche sous la section Handle Standard Output, et affectez à la propriétéWriteBuildMessageMessage la valeur stdOutput.

  3. Faites glisser une activité WriteBuildError de la Boîte à outils pour que l'activité s'affiche sous la section Handle Standard Output, et affectez à la propriété WriteBuildMessageMessage la valeur errOutput.

Vous pouvez utiliser les activités Team Foundation Build pour effectuer les tâches du contrôle de version suivantes :

Utilisez l'activité AssociateChangesetsAndWorkItems pour lier chaque build terminée à tous les ensembles de modifications qui ont été insérés dans le code et leurs éléments de travail associés.

Chaque définition de build gère son propre enregistrement auquel les ensembles de modifications et éléments de travail attendent d'être associés avec la build terminée suivante. Par exemple, l'ensemble de modifications 382 peut être généré à la fois par la Build A et la Build B. La build A est mise en file d'attente et exécutée avec succès, mais la build B est mise en file d'attente et a échoué. L'ensemble de modifications 382 est à présent lié à la build A terminée avec succès et la build B qui a échoué. L'ensemble de modifications 382 ne sera pas lié à la build terminée suivante de la Build A, mais à la build terminée avec succès suivante de la Build B.

Propriété Result de AssociateChangesetsAndWorkItems (IList<Changeset>)

Retourne les ensembles de modifications qui ont été associés à la build.

Propriétés d'argument AssociateChangesetsAndWorkItems

  • CurrentLabel (String) : Laissez cette propriété vide.

  • LastLabel (String) : Laissez cette propriété vide.

  • UpdateWorkItems (Boolean) : Vous pouvez affecter à cette propriété la valeur True si vous souhaitez compléter le champ Corrigé dans des éléments de travail associés au numéro de build. Sinon, définissez la valeur False.

Retour au début

Utilisez l'activité CheckInGatedChanges pour archiver dans le contrôle de version les modifications du code qui ont déclenché une build d'archivage contrôlé. Cette activité associe également la build aux éléments de travail associés aux ensembles de modifications.

Remarque Remarque

Pour fonctionner correctement, cette activité doit être placée après toutes les implémentations des activités MSBuild et MSTest dans votre modèle.

Property Result de CheckInGatedChanges (Changeset)

Retourne l'ensemble de modifications qui contient les modifications en cours d'archivage.

Propriétés d'argument CheckInGatedChanges

  • IgnoreErrors (Boolean): Affectez à cette propriété la valeur False pour pouvoir archiver les fichiers seulement si les propriétés CompilationStatus et TestStatus ont la valeur Succeeded. Affectez à cette propriété la valeur True pour pouvoir archiver les fichiers, indépendamment des valeurs de ces propriétés.

    Remarque Remarque

    Vous pouvez utiliser l'activité SetBuildProperties pour définir les propriétés CompilationStatus et TestStatus.

  • UpdateWorkItems (String) : Vous pouvez affecter à cette propriété la valeur True si vous souhaitez compléter le champ Corrigé dans des éléments de travail associés au numéro de build. Sinon, attribuez-lui la valeur False.

Retour au début

Utilisez l'activité EvaluateCheckInPolicies pour mener des stratégies d'archivage sur le serveur de build. Cette activité permet d'exécuter les stratégies d'archivage en vigueur pour les dossiers spécifiés sur l'onglet Espace de travail de la définition de build. La build échoue si les stratégies d'archivage échouent et la raison pour la build est CheckInShelveset (build d'archivage contrôlé) ou ValidateShelveset (build privée).

Remarque importante Important

Les stratégies d'archivage sont évaluées sur le serveur de builds, pas sur l'ordinateur client du développeur.

L'utilisation la plus efficace de cette activité est l'application de niveaux de qualité renforcés utilisés avec des builds d'archivage contrôlé. Si vous utilisez l'activité de cette façon, l'utilisateur ne peut pas ignorer les stratégies d'archivage. Cette activité est très utile pour les types de stratégies d'archivage suivantes :

  • Stratégie d'archivage Work Items intégrée

  • Stratégies d'archivage personnalisées conçues pour être évaluées sur le serveur de builds

Cette activité n'est pas utile pour évaluer les stratégies d'archivage intégrées Builds ou Code Analysis parce que vous pouvez exécuter ces processus plus efficacement dans une build en utilisant directement les activités MSBuild et MSTest.

Pour plus d'informations, reportez-vous aux ressources suivantes :

Propriétés d'argument EvaluateCheckInPolicies

  • Workspace (Workspace) : Vous devez spécifier l'espace de travail que vous souhaitez évaluer. Dans la plupart des cas, vous devez définir cette propriété avec la variable que vous initialisez dans la propriété Result de l'activité CreateWorkspace. Si vous créez un processus de génération avec le modèle DefaultTemplate.xaml, vous devrez utiliser la variable Workspace.

Retour au début

Vous pouvez étiqueter des fichiers à l'aide des activités de Team Foundation Build :

Vous devez étiqueter les fichiers de code source dans le contrôle de version afin que votre équipe puisse facilement identifier la version de chaque fichier qui fait partie d'une build terminée particulière. Utilisez l'activité LabelWorkspace pour inclure cette étape dans votre processus de génération.

Propriétés d'argument LabelWorkspace

  • Name (String) : Vous devez spécifier le nom de l'étiquette.

  • Child (LabelChildOption) : Vous pouvez spécifier le mode de traitement des éléments qui possèdent déjà des noms correspondant à l'étiquette que vous avez spécifiée. Cette propriété est l'équivalent de l'option /child de la commande tf label.

  • Espace de travail (Workspace) : Vous devez fournir une référence à l'espace de travail de cette génération. Dans la plupart des cas, vous devez définir cette propriété avec la variable que vous initialisez dans la propriété Result de l'activité CreateWorkspace. Si vous créez un processus de génération avec le modèle DefaultTemplate.xaml, vous devrez utiliser la variable Workspace.

  • Comment (String) : Vous pouvez spécifier un commentaire pour l'étiquette. Cette propriété est l'équivalent de l'option /comment de la commande tf label.

  • Scope (String) : Vous pouvez spécifier une portée de l'étiquette. Cette propriété est équivalente à l'argument @scope de la commande tf label.

Pour plus d'informations sur les paramètres tf label, consultez Label Command (Team Foundation Version Control).

Retour au début

Utilisez l'activité LabelSources pour étiqueter les fichiers dans le contrôle de version.

Conseil Conseil

Vous pouvez étiqueter fréquemment les fichiers de code source que vous générez plus efficacement si vous utilisez l'activité LabelWorkspace.

Propriétés d'argument LabelSources

  • Items (IEnumerable<String>) : Vous devez spécifier les éléments à étiqueter. Chaque classe String est équivalente à un argument itemspec de la commande tf label.

  • Name (String) : Vous devez spécifier le nom de l'étiquette.

  • Scope (String) : Vous devez spécifier une portée de l'étiquette. Cette propriété est équivalente à l'argument @scope de la commande tf label.

  • Recursion (RecursionType) : Vous pouvez spécifier Microsoft.TeamFoundation.VersionControl.Client.RecursionType.Full si vous souhaitez étiqueter tous les fichiers dans une hiérarchie de répertoire. Sinon, vous pouvez spécifier Microsoft.TeamFoundation.VersionControl.Client.RecursionType.OneLevel.

  • Version (String) : Vous devez fournir la version des éléments à étiqueter. Cette propriété est l'équivalent de l'option /version de la commande tf label.

  • Child (LabelChildOption) : Vous pouvez spécifier le mode de traitement des éléments qui possèdent déjà des noms correspondant à l'étiquette que vous avez spécifiée. Cette propriété est l'équivalent de l'option /child de la commande tf label.

  • Comment (String) : Vous pouvez spécifier un commentaire pour l'étiquette. Cette propriété est l'équivalent de l'option /comment de la commande tf label.

Pour plus d'informations sur les paramètres tf label, consultez Label Command (Team Foundation Version Control).

Retour au début

Utilisez l'activité QueryShelvesets pour obtenir une liste de jeux de réservations qui répondent à vos critères. Vous pouvez ensuite utiliser l'activité TfUnshelve pour récupérer le contenu d'un des jeux de réservations.

Résultat de QueryShelvesets (IList<Shelveset>)

Propriétés d'argument de QueryShelvesets

Cette activité encapsule la Get, commande.

Cette activité encapsule la Resolve Command.

Cette activité encapsule la Shelve, commande.

Cette activité encapsule la Undo, commande.

Cette activité encapsule la Unshelve, commande.

Cette activité encapsule la Workfold Command.

Vous pouvez utiliser des éléments de travail avec les activités de Team Foundation Build :

Utilisez l'activité OpenWorkItem pour créer un élément de travail.

Propriété Result de OpenWorkItem (WorkItem)

Retourne le nouvel élément de travail.

Propriétés d'argument OpenWorkItem

  • AssignedTo (String) : Vous devez spécifier la personne à laquelle vous souhaitez assigner l'élément de travail.

  • Title (String) : Vous devez spécifier le titre de l'élément de travail.

  • Type (String) : Vous devez spécifier le type de l'élément de travail. Les valeurs Type classiques comprennent les exemples suivants : “Bug”, “Issue” et “Task”.

  • Comment (String) : Vous pouvez ajouter un commentaire à l'historique de l'élément de travail.

  • CustomFields (IDictionary<String,String>) : Vous pouvez définir la valeur d'un ou plusieurs champs de l'élément de travail.

Retour au début

Vous pouvez utiliser des données de symboles en utilisant deux activités de Team Foundation Build : IndexSources etPublishSymbols.

Une utilisation typique de ces activités consiste à activer le débogage IntelliTrace. Si vous souhaitez activer le débogage IntelliTrace, vous devez d'abord appeler l'activité IndexSources pour préparer vos données de symboles, puis vous devez appeler l'activité PublishSymbols pour publier les données dans un magasin de symboles SymStore.

Pour plus d'informations sur le débogage IntelliTrace, consultez Débogage du code plus rapide en examinant son historique avec IntelliTrace.

Utilisez l'activité IndexSources pour intégrer des chemins d'accès et des versions de contrôle de version dans les données de symboles dans vos fichiers .pdb.

Propriétés d'argument IndexSources

  • FileList (IEnumerable<String>) : Vous devez spécifier le chemin d'accès complet et le nom de chaque fichier de symboles. Vous pouvez utiliser l'activité FindMatchingFiles pour fournir cet argument.

    Vous pouvez utiliser ** pour spécifier une recherche récursive. Par exemple, vous pouvez appeler FindMatchingFiles avec la valeur suivante dans la propriété MatchPattern : String.Format("{0}\**\*.pdb", BinariesDirectory).

Retour au début

Utilisez l'activité PublishSymbols pour publier les données de symboles de vos fichiers PDB dans un magasin de symboles SymStore. Cette activité est essentiellement un wrapper sur SymStore.exe. Pour plus d'informations sur les magasins de symboles SymStore et la manière d'en préparer un, consultez Indexer et publier des données symboles.

Remarque importante Important

Les données peuvent être endommagées si des générations simultanées tentent de publier dans le même partage de fichiers de symboles. Pour éviter ce problème, vous devez appeler cette activité uniquement à l'intérieur d'une activité SharedResourceScope.

Propriété Result de PublishSymbols (String)

Retourne l'ID de transaction que SymStore.exe retourne.

Propriétés d'argument PublishSymbols

  • FileList (IEnumerable<String>) : Vous devez spécifier le chemin d'accès complet et le nom de chaque fichier de symboles. Vous pouvez utiliser l'activité FindMatchingFiles pour fournir cet argument.

    Par exemple, vous pouvez appeler FindMatchingFiles avec la valeur suivante dans la propriété MatchPattern : String.Format("{0}\**\*.pdb", BinariesDirectory).

  • StorePath (String) : Vous devez spécifier le chemin d'accès du fichier UNC au dossier racine du magasin de symboles SymStore.

  • CommandLineArguments (String) : pour plus d'informations sur les autres arguments que vous pouvez passer à SymStore.exe, consultez Options de ligne de commande SymStore (page éventuellement en anglais).

  • Comments (String) : Vous pouvez spécifier les commentaires de transaction qui sont stockés dans le fichier historique d'historique des transactions dans le magasin de symboles. Cette propriété est l'équivalent du paramètre /c Comment de la commande SymStore.exe. Pour plus d'informations, consultez Options de ligne de commande SymStore.

  • ProductName (String) : Vous pouvez spécifier le nom du produit qui est stocké dans le fichier historique des transactions dans le magasin de symboles. Par exemple, vous pouvez affecter à cette propriété le nom de définition de build (Name), que vous pouvez obtenir dans la propriété BuildDefinition en appelant GetBuildDetail. Cette propriété est l'équivalent du paramètre /t Product de la commande SymStore.exe. Pour plus d'informations, consultez Options de ligne de commande SymStore.

  • StoreCompressed (Boolean) : Vous pouvez affecter à cette propriété la valeur True pour stocker des fichiers dans le magasin de symboles sous la forme de fichiers compressés. Sinon, les fichiers seront stockés sans compression. Cette propriété est l'équivalent du paramètre /compress de la commande SymStore.exe. Pour plus d'informations, consultez Options de ligne de commande SymStore.

  • Version (String) : Par exemple, vous pouvez affecter à cette propriété le numéro de build (BuildNumber) que vous pouvez obtenir en appelant GetBuildDetail. Cette propriété est l'équivalent du paramètre /v Version de la commande SymStore.exe. Pour plus d'informations, consultez Options de ligne de commande SymStore.

Retour au début

Vous pouvez obtenir des références aux objets utiles à l'aide des activités de Team Foundation Build.

Utilisez l'activité GetTeamProjectCollection pour obtenir, à partir de sa propriété Result, une référence à un objet TfsTeamProjectCollection. Cet objet de démarrage est important. Vous pouvez par exemple l'utiliser pour vous connecter à un serveur de couche Application de Team Foundation.

Utilisez l'activité GetBuildAgent pour obtenir, à partir de sa propriété Result, une référence à l'objet IBuildAgent. Vous pouvez utiliser cette activité uniquement dans une activité AgentScope.

Utilisez l'activité GetBuildDetail pour obtenir, à partir de sa propriété Result, une référence à l'objet IBuildDetail. Vous pouvez utiliser cet objet pour obtenir, et dans certains cas définir, des données sur la build en cours.

Retour au début

Utilisez l'activité GetBuildEnvironment pour obtenir, via sa propriété Result, une référence à l'objet BuildEnvironment. Vous utilisez en général cette propriété pour effectuer les tâches suivantes :

  • Utilisez l'objet Environment pour déterminer si le segment en cours du flux de travail est en cours d'exécution sur le contrôleur de build ou l'agent de build.

  • Utilisez l'objet CustomAssemblyPath pour obtenir le chemin d'accès aux assemblys qui contiennent les activités personnalisées sur l'agent de build.

Retour au début

Certains activités ne sont pas prévues d'être modifiées dans un processus de génération personnalisé.

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Non documenté dans la version actuelle.

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ignorez cette activité.

Retour au début

Ajouts de la communauté

Afficher: