Définir un processus de génération d'archivage contrôlé pour la validation des modifications

Lorsqu'un développeur archive des modifications qui arrêtent la build, cela peut avoir des conséquences néfastes sur le travail des petites équipes.Pour les équipes de plus grande taille, les coûts en matière de perte de productivité et de retard dans le planning peuvent être encore plus élevés.Vous avez donc tout intérêt à créer une définition de build d'archivage contrôlé afin de mettre tout ou partie de votre base de code à l'abri de ces problèmes.

Dans cette rubrique

• Incidence des builds d'archivage contrôlé sur votre équipe.

• Pour définir un processus de build d'archivage contrôlé

• Indications pour améliorer les fonctions et les performances du processus de build

• Éviter de bloquer votre équipe

• Exécuter manuellement des builds d'archivage fermés et des builds privées

Incidence des builds d'archivage fermés sur votre équipe.

Lorsque votre équipe met un processus de build d'archivage contrôlé en place, les modifications que les développeurs envoient sont placées dans des jeux de réservations et sont automatiquement générés et testés probablement par votre système de génération.

Le processus d'archivage ne sera effectif que si la génération réussit.Pour plus d'informations, consultez Archiver des modifications en attente contrôlées par une build d'archivage contrôlé.

Si certains de vos utilisateurs doivent passer au travers de l'archivage contrôlé, veillez à ce que l'autorisation Remplacer la validation de l'archivage par build ait la valeur Autoriser pour le groupe d'utilisateurs en question.Pour plus d'informations, consultez Autorisations de Team Foundation Server.

Pour définir un processus de build d'archivage contrôlé

Autorisations requises

Pour que vous puissiez effectuer cette procédure, l'autorisation Modifier la définition de build doit avoir la valeur Autoriser.Pour plus d'informations, consultez Autorisations de Team Foundation Server.

Pour définir une build d'archivage contrôlé

1. Dans l'Explorateur d'équipes :

   1. Si vous n'êtes pas déjà connecté au projet d'équipe dans lequel vous souhaitez travailler, connectez-vous au projet d'équipe.

   2. Sélectionnez Home, puis choisissez Builds.

   3. Sur la page Builds, choisissez Nouvelle définition de build.

   Une nouvelle fenêtre de définition de build s'affiche.

2. Sur l'onglet Déclencheur.

   • Choisissez archivage contrôlé.

   • (Facultatif) pour augmenter l'efficacité de votre processus de génération, sélectionnez Fusionnez et augmenter jusqu'à n envois pour plus d'informations, consultez Éviter de bloquer votre équipe.

3. Dans l'onglet Workspace , dans la table Working folders , mappez les dossiers de contrôle de version que cette définition de build contrôlera dans les dossiers locaux sur l'agent de build.

   Conseil

   Respectez les règles ci-dessous. Pour vous assurer que votre build traite les fonctions correctement et pour améliorer les performances, incluez tous les dossiers—et seulement ces dossiers—qui contiennent les fichiers requis par votre processus de build. Assurez vou que vous ne spécifiez pas un dossier de contrôle de version déja spécifié dans l' Espace de travail des autres définitions de build d'archivage contrôlé.Sinon, quand un utilisateur archive des fichiers dans ces dossiers, le système de build à besoin qu'il décide quelle définition de build doit être mise en file d'attente. Pour plus d'informations sur comment spécifier les mappages, consultez Travailler avec des espaces de travail de build.

4. Sous l'onglet Valeurs par défaut des builds , pour améliorer les performances, choisissez Cette génération ne copie pas des fichiers de sortie vers un dossier de dépôt.

5. Dans Processus , sous Modèle de processus de build, Le modèle par défaut est sélectionné par défaut.Dans le paramètre Éléments à générer , spécifiez les solutions ou des projets de code à générer.

6. Sous l'onglet Processus , définissez les paramètres de processus de génération pour vous assurer que les enregistrements sont conformes aux standards spécifiques pour la qualité du code de votre équipe sans différer vos développeurs inutilement.

   Pour plus d'informations, consultez indications pour améliorer la fonction et la représentation de processus de génération plus loin dans cette rubrique.

7. Spécifiez les options de processus de build sur les autres onglets.Pour plus d'informations, consultez Créer une définition de build.

Indications pour améliorer les fonctions et les performances du processus de build

Pour réduire la durée nécessaire au traitement de la build, vous devez suivre ces instructions lorsque vous spécifiez des valeurs pour les paramètres de processus de génération sous l'onglet Processus.

Nœud obligatoire

• Éléments à générer, Configurations à générer : si vous laissez ce paramètre vide, la plateforme et la configuration par défaut sont utilisées pour chaque solution et projet.Pour optimiser les performances, respectez les instructions suivantes :

  • Si une paire plateforme/configuration est générée plus rapidement que d'autres paires, spécifiez-la dans ce paramètre.

  • Spécifiez le moins de paires plateforme/configuration possible.

Nœud de base

• Nettoyer l'espace de travail : Pour améliorer des performances, spécifiez la valeur Aucun (recommandé) ou Sorties.Toutefois, votre équipe risque de laisser passer certains types d'erreurs, tels que ceux présentés pendant la refactorisation, si l'espace de travail n'est pas nettoyé.Pour plus d'informations, consultez Définir un processus de build basé sur le modèle par défaut.

• Effectuer l'analyse du code : Pour des des meilleures performances, choisissez Jamais.

• Paramètres de serveur source et de symboles, Sources d'index : Pour de meilleures performances, spécifiez la valeur False.

Nœud avancé

• Paramètres d'agent

  • Filtre de nom ou Filtre de balises : utilisez un nom d'agent de build ou une balise pour lier cette définition de build à un agent de build conçu spécialement pour l'exécution de cette build.L'agent de build doit être exécuté sur une machine de build offrant une capacité de traitement conforme aux attentes de votre équipe en termes de performances.

    Par exemple, vous et les développeurs de votre équipe feront certainement preuve de patience si la durée du processus de génération ne dépasse pas 15 minutes.Mais ils ne peuvent pas se permettre d'attendre huit heures pour savoir si l'archivage de votre code ne pose aucun problème.

  • Durée d'exécution maximale : choisissez un délai relativement court.Il est fort probable qu'un délai de huit heures soit trop long pour votre équipe et qu'un délai de 15 minutes soit acceptable.

• Créer un élément de travail en cas d'échec : le système prend cette valeur comme False, même si vous lui affectez la valeur True.

• Désactiver des tests:

  • Pour accélérer les performances, sélectionnez True.

  • Si votre code doit passer certains tests, sélectionnez False puis définissez un ensemble de tests pour éxécuter le build.Vous pouvez améliorer les performances en exécutant seuls les tests dont vous avez besoin.Pour lire ces tests, filtrez-les par catégorie ou priorité.Pour plus d'informations, consultez Exécuter des tests dans votre processus de génération.

• Sources d'étiquettes : choisissez la valeur False.

Pour plus d'informations sur les paramètres du modèle de processus de build, consultez Définir un processus de build basé sur le modèle par défaut.

Éviter de bloquer votre équipe

Chaque définition de build d'archivage contrôlé peut avoir une seule build en cours d'exécution à la fois.Par conséquent, les équipes actives et de grande envergure sont plus susceptibles de développer une grande file d'attente de builds d'archivage contrôlé.Les meilleures pratiques suivantes peuvent vous aider à éviter tout blocage de la progression de votre équipe:

• Pour augmenter l'efficacité de votre processus de génération, sur l'onglet Déclencheur , sélectionnez l'option Fusionnez et augmenter jusqu'à n envois et spécifier le nombre maximal d'enregistrements que vous souhaitez générer ensemble dans tout traitement donné.En général vous ne risquez pas beaucoup d'interruption en utilisant cette option.Chaque archivage est validé individuellement ou rejeté.

  Par exemple, si trois enregistrements sont générés ensemble dans un processus et que la génération n'aboutit pas, le système met en file d'attente des builds individuelles de chacun des trois enregistrements.

  Toutefois, cette option présente le risque qu'un archivage interfère avec d'autres.Cela peut se produire, par exemple, si plusieurs enregistrements modifient le même fichier et un conflit de contrôle de version se produit.Dans ce cas, l'archivage antérieur est validé et les archivages ultérieurs sont rejetés.

• Définissez la build de sorte que l'agent de build effectue uniquement le travail qui est nécessaire pour valider la qualité du code archivé.Pour plus d'informations, consultez Instructions pour les paramètres de l'onglet Processus plus haut dans cette rubrique.

• Consacrez un ordinateur de build équipé d'un matériel puissant—par exemple, un processeur rapide et un disque dur rapide—à l'agent de build utilisé par votre définition de build d'archivage contrôlé.

Exécuter manuellement des builds d'archivage contrôlé et des builds privées

Les développeurs qui souhaitent contrôler plus étroitement les modifications qu'ils archivent peuvent mettre manuellement en file d'attente une build d'un jeu de réservations.Dans ce cas, ils peuvent choisir l'une des deux options suivantes afin de spécifier l'action effectuée par le système si la génération réussit :

• Le système archive les modifications (build d'archivage contrôlé manuel) : cette option peut être pratique pour les équipes qui nécessitent l'archivage contrôlé mais qui souhaitent permettre aux développeurs de valider volontairement leur code avant de l'archiver.

• Le système n'archive pas les modifications (build privée) : les développeurs peuvent utiliser cette option lorsqu'ils souhaitent valider des modifications dans un jeu de réservations sans toutefois les archiver.

Pour plus d'informations, consultez Mettre une build en file d'attente.