SDLC Mangement pour les scripts de construction TFS

Question

Je suis en train de développer plusieurs scripts de construction personnalisés pour TFS et j'aimerais savoir s'il existe des bonnes pratiques pour développer, tester et déployer des scripts de construction TFS.

Configurez-vous des environnements de développement et de contrôle de la qualité qui sont séparés du serveur de génération de production? Existe-t-il d'autres moyens d'isoler le processus de développement des scripts du reste du processus de génération afin que les scripts de construction en cours de développement n'interfèrent pas avec les versions "de production"? Team Build aime créer des éléments de travail, mettre à jour des éléments de travail et ajouter des étiquettes dans le cadre du processus de construction que je n'aurais pas réalisé pour une version "test".

JMM

Answer 1

Vérifiez ma réponse ici: Modular TeamBuilds

Vous pouvez conserver les fonctionnalités de base refactorisée dans un fichier MSBuild commun qui est inclus dans toutes les versions. En outre, tous ces fichiers font partie de votre structure de branche plus large, de sorte qu'ils participent directement à votre SDLC préexistant sans aucun travail supplémentaire. Ainsi:

1. Si vous faites des changements risqués à vos scripts de construction, faites-les dans une branche «dev» ou «privée», comme vous le feriez avec d'autres changements risqués.
2. Si vous voulez une définition de construction qui est juste pour la validation rapide, définissez les propriétés comme SkipLabel, SkipWorkItemCreation, etc à False dans le fichier * .targets importé par cette définition de construction.

Pour développer un peu sur le n ° 2, prenons votre exemple de builds "production" vs "test". Vous souhaitez uniquement activer des fonctionnalités telles que l'étiquetage dans les versions de production. Ainsi, vous supprimez la propriété SkipLabel de TFSBuild.proj (et aussi TFSBuild.Common.targets si elle est définie ici) et la placez dans TFSBuild.Production.targets et TFSBuild.Test.targets en utilisant deux valeurs différentes, bien sûr.

Comme mentionné dans la question précédente, TFSBuild.proj est le fichier maître msbuild qui contrôle le fonctionnement du reste de la construction. Voilà ce que le mien ressemble:

<?xml version="1.0" encoding="utf-8"?> 

<!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions 
    and projects in the SolutionToBuild item group from targeting other versions of the .NET framework. 
    --> 
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 

    <!-- Import configuration for all MyCompany team builds --> 
    <Import Project="MyCompany.TeamBuild.Common.targets"/> 

    <!-- Import build-specific configurations --> 
    <Import Condition="'$(BuildDefinition)'=='Dev - quick'"  Project="MyCompany.TeamBuild.Quick.targets" /> 
    <Import Condition="'$(BuildDefinition)'=='Main - full'"  Project="MyCompany.TeamBuild.Full.targets" /> 
    <Import Condition="'$(BuildDefinition)'=='Main - quick'" Project="MyCompany.TeamBuild.Quick.targets" /> 
    <Import Condition="'$(BuildDefinition)'=='Release - full'" Project="MyCompany.TeamBuild.Full.targets" /> 

    <!-- This would be much cleaner as we add more branches, but msbuild doesn't support it :(
     Imports are evaluated declaratively at parse-time, before any tasks execute 
    <Target Name="BeforeEndToEndIteration"> 
     <RegexReplace Input="$(BuildDefinition)" Expression=".*\s-\s" Replacement=""> 
     <Output TaskParameter="Output" PropertyName="BuildType" /> 
     </RegexReplace> 
    </Target> 
    <Import Condition="$(BuildType)==full" Project="MyCompany.TeamBuild.Full.targets" /> 
    <Import Condition="$(BuildType)==quick" Project="MyCompany.TeamBuild.Quick.targets" /> 
    --> 
</Project> 

En faisant quelque chose de similaire, vous pouvez faire en sorte que toutes les versions de la branche Dev sont « rapide » builds (qui vous signifie pas l'étiquetage, etc.), toutes les versions de la branche de sortie sont des versions "complètes", et les constructions à partir de la branche principale peuvent être soit en fonction de la définition de construction que l'utilisateur lance à partir de Visual Studio/TSWA. Moi-même, j'ai des builds "rapides" avec une intégration continue et des builds "complets" tous les soirs.