Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Personnaliser un modèle de processus

Un modèle de processus correspond à un ensemble interdépendant de fichiers utilisés pour créer un projet d'équipe Team Foundation Server (TFS). Un projet d'équipe est un outil de planification central qui vous permet de suivre les informations et d'organiser le code source, les builds, les tests et les plans de votre équipe. En plus de créer un projet d'équipe, vous utilisez un modèle de processus TFS pour mettre à niveau un projet d'équipe existant après une mise à niveau vers un serveur TFS local.

Si vous recherchez des modèles de projet pour le développement de logiciels, consultez Création de modèles Visual Studio. Cette rubrique traite des modèles de processus pour la création de projets d'équipe TFS.

Un modèle de processus TFS définit plusieurs configurations par défaut ainsi que les artefacts suivants que votre équipe utilise pour collaborer, partager des informations, planifier le travail et en effectuer le suivi.

Artefacts du modèle de processus TFS 2013 Agile

Artefacts du modèle de processus TFS 2013 Agile

La plupart de ces artefacts dépendent de la création et de la définition des objets qui sont définis pour le suivi du travail. Par exemple, les champs de données définis dans la définition des types d'éléments de travail (comme Fonctionnalité, Bogue, Récit utilisateur ou Tâche) sont également utilisés pour définir des requêtes d'élément de travail et des rapports. Outre ces artefacts, vous pouvez également définir les zones et jalons du projet initial, la configuration de la sécurité et d'autres paramètres par défaut qui prennent en charge le contrôle de version et la gestion des tests.

Après avoir créé un projet d'équipe, vous pouvez modifier les configurations et personnaliser des artefacts. Cependant, en personnalisant le modèle de processus avant de créer vos projets d'équipe, tous les projets d'équipe qui en sont issus correspondent à un ensemble standard de processus d'équipe. Les principales raisons pour lesquelles personnaliser un modèle de processus sont les suivantes :

  • Vous envisagez de créer plusieurs projets d'équipe et vous voulez réduire les tâches répétitives à mettre en place plus tard dans chaque projet d'équipe que vous allez créer.

  • Vous voulez vous assurer que toutes les équipes respectent certaines normes en fournissant les modèles et structures au sein de l'ensemble d'outils qu'utilisent vos équipes de développement de logiciels.

  • Vous devez mettre à jour un modèle de processus personnalisé pour prendre en charge l'utilisation de l'Assistant Configurer les fonctionnalités après une mise à niveau de TFS.

Si vous utilisez un seul projet d'équipe, vous pouvez envisager de simplement le créer et d'en personnaliser un ou plusieurs objets.

Avant de commencer la personnalisation d'un modèle de processus, vous devrez vous familiariser avec ce que vous pouvez configurer et personnaliser, puis planifier vos modifications en conséquence.

Les modèles de processus se composent de neuf plug-ins. Chaque plug-in définit un ensemble de tâches à exécuter et les écrans qui s'affichent quand vous lancez l'Assistant Nouveau projet d'équipe. Les tâches consistent à définir des autorisations, créer des dossiers, télécharger des fichiers, activer des sites ou définir d'autres variables configurables. Les plug-ins spécifient également les dépendances d'une tâche pour le bon déroulement d'autres tâches.

Plug-ins de modèles de processus

Pour personnaliser un modèle de processus, vous personnalisez un ou plusieurs fichiers associés à un domaine fonctionnel. Même s'il est plutôt simple de personnaliser un objet, veillez à ne rompre aucune interdépendance.

Étant donné que le modèle de processus concerne de nombreux composants du processus d'une équipe, envisagez de planifier, coordonner et suivre les modifications que vous allez apporter. En particulier, vous pouvez consulter les chefs de projet, responsables des tests, responsables du développement et les gestionnaires de versions avant de modifier la configuration par défaut d'une zone.

La personnalisation d'un modèle de processus est un processus itératif. Vous avez besoin d'une collection de projets d'équipe définie sur un serveur qui exécute Team Foundation Server où vous pouvez tester votre modèle de processus pour vous assurer qu'il a été correctement personnalisé.

Pour personnaliser un modèle de processus, vous téléchargez tout d'abord un modèle de processus existant, vous modifiez ou ajoutez des fichiers, vous transférez les fichiers du modèle de processus, puis vous vérifiez vos modifications.

Flux de travail de la personnalisation des modèles de processus

Step

Tâche

Étape 1

Télécharger un modèle de processus. Avant de pouvoir personnaliser un modèle de processus, vous devez le télécharger sur votre ordinateur local.

Pour limiter les modifications à apporter, sélectionnez un modèle qui correspond au mieux à vos processus d'équipe. En général, vous choisissez un modèle de processus en fonction des types d'éléments de travail et du flux de travail.

Étape 2

Modifier ou ajouter des fichiers. Vous personnalisez un modèle de processus en modifiant, en supprimant ou en ajoutant des fichiers définis pour un modèle de processus. Vous personnalisez un fichier de plug-in ou de définition en modifiant son contenu XML. Chaque fichier de plug-in et de définition de type doit être conforme à sa définition de schéma XML.

La première fois que vous personnalisez un modèle de processus, effectuez une petite modification. Si vous apportez de nombreuses modifications sans savoir comment elles sont susceptibles d'affecter le modèle, vous risquez de rencontrer de multiples erreurs difficiles à déboguer.

Assurez-vous que le nom de votre modèle de processus est unique. Si vous téléchargez un modèle de processus, y apportez des modifications, puis le transférez, vous devez modifier son nom sans quoi il va écraser le modèle de processus existant dans la collection de projets.

Étape 3

Transférer un modèle de processus. Une fois que vous avez personnalisé votre modèle, transférez-le à la collection de projets d'équipe où vous allez créer le projet d'équipe.

Dans l'idéal, vous devez utiliser une collection de projets d'équipe qui n'est pas utilisée par d'autres projets d'équipe. En travaillant dans une collection de projets de banc d'essai, vous évitez d'introduire une modification pouvant entrer en conflit avec des processus d'équipe existants encore en cours de développement. En outre, vous voulez que la collection de projets d'équipe prenne en charge les mêmes ressources que celles auxquelles vous voulez que les membres d'équipe puissent accéder, par exemple un portail de projet et un site de génération de rapports.

Assurez-vous que le nom de votre modèle de processus est unique. Si vous avez téléchargé un modèle de processus à partir d'une collection de projets d'équipe, puis apporté une modification et que vous transférez à présent le modèle, vous devez modifier son nom ou supprimer le modèle de processus existant de la collection de projets d'équipe.

Le processus de transfert exécute une vérification pour s'assurer que le code XML est valide. Si vous recevez des erreurs quand vous essayez de transférer le modèle de processus, les modifications que vous avez apportées en sont la cause. Passez en revue vos modifications et corrigez les éventuelles erreurs de syntaxe XML que vous trouvez.

Étape 4

Créer un projet d'équipe. Pour tester les nouveaux modèles de processus, vous devez créer un projet d'équipe. Vous créez un projet d'équipe en accédant à l'Assistant Nouveau projet d'équipe à partir de Team Explorer.

Si des erreurs se produisent, consultez le journal de création du projet d'équipe. Il contient la liste des tâches dont l'exécution a été tentée et indique celles qui ont échoué. Vous pouvez mapper les tâches qui ont échoué sur le XML pour déterminer la cause des erreurs.

Vous pouvez nettoyer les projets d'équipe superflus à l'aide de l'outil en ligne de commande TFSDeleteProject.

Étape 5

Vérifiez les modifications apportées aux modèles de processus. Avant de mettre votre modèle de processus en mode de production et de l'utiliser comme base de plusieurs projets d'équipe, vous devez vérifier qu'il est correctement défini. Pour effectuer cette tâche, vous vérifiez systématiquement que chaque objet et chaque artefact fonctionnent comme prévu.

Si vous avez ajouté un rapport, assurez-vous qu'il apparaît dans Team Explorer. Si vous avez ajouté un champ, assurez-vous que vous n'avez pas introduit de conflits de schéma.

R : oui. Parfois, des modèles de processus créés par des tiers sont disponibles. Ils peuvent avoir besoin d'être remaniés après une mise à niveau de TFS, comme indiqué ici.

Vous pouvez effectuer une recherche sur CodePlex.com pour déterminer si des modèles de processus y ont été téléchargés.

R : Pour télécharger ou transférer des modèles de processus, soit vous devez être membre du groupe Project Collection Administrators, soit votre autorisation Gérer le modèle de processus doit être définie sur Autoriser. Voir Ajouter des comptes pour administrer des collections de projets.

R : Vous pouvez utiliser n'importe quel éditeur de texte ou éditeur XML pour modifier des fichiers XML. Vous pouvez également utiliser Process Editor, un outil puissant pour Visual Studio pour personnaliser des fichiers de modèles de processus. Pour le télécharger, accédez à Team Foundation Server Power Tools.

Process Editor fournit une interface utilisateur qui vous permet de personnaliser les zones suivantes :

  • Suivi des éléments de travail :

    • Créer et modifier des définitions pour les types d'éléments de travail, notamment ajouter des champs, modifier des flux de travail et des formulaires d'éléments de travail

    • Ajouter ou modifier des catégories pour le regroupement des types d'éléments de travail

    • Modifier la configuration du processus pour les outils de planification Agile

    • Créer et modifier des requêtes d'éléments de travail et organiser les requêtes dans des dossiers

    • Créer et modifier des types de liens

  • Classifications et hiérarchies des projets :

    • Créer et modifier des chemins de zone produit

    • Créer et modifier des versions de jalons ou des chemins d'itération

    • Modifier le fichier de mappage pour Microsoft Project

  • Groupes de sécurité : Créer et modifier les groupes TFS et leurs autorisations

  • Contrôle de version :

    • Modifier les paramètres d'extraction

    • Créer et modifier des notes d'archivage

    • Créer et modifier les groupes TFS et leurs autorisations

  • Portail et rapports :

    • Consulter les fichiers à transférer et leur structure de dossiers

    • Ajouter des fichiers à transférer

R : Les plug-ins Build, Portail et Création de rapports nécessitent ces ressources.

Plug-in

Team Foundation Build

Produits SharePoint

SQL Server 2008 Analysis Services

SQL Server 2008 Reporting Services

Compilation

Obligatoire

Portail

Obligatoire

Obligatoire Recommandé

Requis uniquement pour prendre en charge les tableaux de bord de base

Création de rapports

Obligatoire Obligatoire

R : oui. Vous ne pouvez pas personnaliser les rapports et tableaux de bord Microsoft Excel via les fichiers de modèles de processus. Ces artefacts sont créés pour un projet d'équipe en fonction des sélections que vous effectuez dans l'Assistant Nouveau projet d'équipe. Pour plus d'informations, consultez Customizing Team Foundation Server Project Portals.

R : Vous utilisez le fichier de plug-in ProcessTemplate.xml pour définir les plug-ins à inclure dans le modèle. Ce fichier contient tous les groupes de tâches à exécuter pour créer un projet d'équipe. Chaque groupe de tâches fait référence à un fichier de plug-in XML subordonné où les tâches spécifiques de ce plug-in sont définies. Cliquez ici pour plus d'informations.

R : De nombreux objets s'appuient sur la définition d'autres objets au sein d'un modèle de processus.

Par exemple, les requêtes d'éléments de travail définies pour le modèle de processus Agile utilisent les nœuds d'itération définis dans le fichier Classification.xml. Si vous modifiez les définitions des nœuds d'itération, vous devez modifier les requêtes d'éléments de travail sur lesquelles elles reposent. Pour trouver ces requêtes, recherchez les macros suivantes dans les fichiers .wiq :

  • Iteration 1 = @@Iteration%201@@

  • Iteration 2 = @@Iteration%202@@

  • Iteration 3 = @@Iteration%203@@

Pour obtenir une vue d'ensemble des plug-ins requis et de leurs dépendances, consultez Définir les dépendances pour les groupes de tâches et les tâches dans les fichiers de plug-in.

R : oui. Quand vous ajoutez des objets à un modèle de processus, vous devez veiller à les étiqueter correctement pour éviter les erreurs de validation XML.

Prenez connaissance des remarques et conseils suivants :

  • Il existe des restrictions sur les noms ou étiquettes de la plupart des objets Team Foundation. Pour obtenir une vue d'ensemble des restrictions d'appellation qui s'appliquent aux modèles de processus, groupes de sécurité, nœuds de zone et d'itération, types d'éléments de travail et champs d'éléments de travail, consultez Restrictions d'affectation de noms dans Team Foundation.

  • La plupart des composants de modèle de processus que vous personnalisez affectent uniquement le projet d'équipe que vous créez à l'aide du modèle de processus. Les exceptions à cette règle sont les listes globales, des types de liens et les champs d'éléments de travail qui sont définis pour les types d'éléments de travail. Ces objets sont définis pour une collection de projets d'équipe.

  • Chaque champ d'élément de travail possède un nom de référence de champ associé qui identifie chaque champ de façon unique. Vous ne pouvez pas modifier le nom de référence une fois qu'il est affecté.

    En outre, un champ d'élément de travail peut posséder un nom de rapport associé. Le nom du rapport doit être identique dans tous les types d'éléments de travail définis pour une collection de projets d'équipe. Dans le cas contraire, des erreurs de validation peuvent se produire quand vous transférez le modèle de processus ou des conflits peuvent survenir dans les bases de données de l'entrepôt de données.

    Les noms de champs des éléments de travail, les noms des types de liens et les listes globales s'étendent sur une collection de projets d'équipe. Si vous personnalisez un de ces objets, la modification se répercute dans tous les projets d'équipe définies dans la collection et dans les types d'éléments de travail qui contiennent ce champ d'élément de travail.

    Pour plus d'informations, consultez Conventions d'affectation de noms pour les objets de suivi des éléments de travail.

  • La taille maximale d'un modèle de processus s'élève à deux gigaoctets. Quand vous personnalisez un modèle de processus, veillez à ce que vos modifications n'augmentent pas sa taille au-delà de cette valeur.

R : Les fichiers de modèles de processus référencent deux définitions de schéma principales. Les fichiers de plug-in se basent sur les schémas de modèles de processus et les définitions de types d'éléments de travail se basent sur le schéma du suivi du travail.

Ajouts de la communauté

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft