TFS构建脚本的SDLC管理 [英] SDLC Mangement for TFS Build Scripts

问题描述

我正在为TFS开发多个自定义构建脚本，我想知道是否有用于开发，测试和部署TFS构建脚本的最佳实践.

I'm in the process of developing several custom build scripts for TFS and I'd like to know if there are any best practices for developing, testing and deploying TFS build scripts.

您是否设置了与生产构建服务器分开的开发和QC环境?还有其他方法可以将脚本开发过程与其余构建过程隔离开，从而使正在开发的构建脚本不会干扰生产"构建吗?

Do you setup development and QC environments that are seperate from the production build server? Are there other ways to isolate the process of developing the scripts from the rest of the build process so that builds scripts under development don't interfere with "production" builds?

Team Build喜欢创建工作项，更新工作项并添加标签，这是我不希望进行测试"构建的构建过程的一部分.

Team Build likes to create work items, update work items and add labels as part of the build process which I'd rather not have happen for a "test" build.

jMM

推荐答案

在此处查看我的答案:模块化TeamBuilds

Check out my answer here: Modular TeamBuilds

您可以将核心功能分解为所有版本中都包含的通用MSBuild文件.此外，所有这些文件都是您更广泛的分支结构的一部分，因此它们无需任何额外工作即可直接参与您先前存在的SDLC.因此:

You can keep core functionality factored out into a common MSBuild file that's included across all builds. Furthermore, all of these files are part of your broader branch structure, so they participate directly in your preexisting SDLC without any extra work. Thus:

1. 如果您要对构建脚本进行危险的更改，请像在进行其他任何危险的更改一样，将其置于"dev"或"private"分支中.
2. 如果您想要一个仅用于快速验证的构建定义，请在该构建定义导入的* .targets文件中将SkipLabel，SkipWorkItemCreation等属性设置为False.

为了稍微扩展一下#2，让我们以生产"与测试"构建为例.您只想打开生产版本中的标签等功能.因此，您可以从TFSBuild.proj(以及在其中定义的TFSBuild.Common.targets)中删除SkipLabel属性，并在TFSBuild.Production.targets和TFSBuild.Test.targets中进行设置-当然，使用两个不同的值.

To expand on #2 a bit, let's take your example of "production" vs "test" builds. You only want to turn on features like labeling in production builds. So you would remove the SkipLabel property from TFSBuild.proj (and also TFSBuild.Common.targets if it's defined there) and instead set it in TFSBuild.Production.targets and TFSBuild.Test.targets -- using two different values, of course.

如前面的问题所述，TFSBuild.proj是主msbuild文件，用于控制其余构建方式的运行方式.这是我的样子:

As mentioned in the earlier question, TFSBuild.proj is the master msbuild file that controls how the rest of the build will operate. Here's what mine looks like:

<?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>

通过类似的操作，您可以确保Dev分支中的所有构建都是快速"构建(这对您来说意味着没有标签等)，Release分支中的所有构建都是完整"构建，并且主分支可以取决于用户从Visual Studio/TSWA启动的构建定义.就我自己而言，我已经使用持续集成"设置了快速"构建，并且每晚运行了完整"构建.

By doing something similar, you can ensure that all builds from the Dev branch are "quick" builds (which for you means no labeling, etc), all builds from the Release branch are "full" builds, and builds from the Main branch can be either depending on which build definition the user launches from Visual Studio / TSWA. Myself, I have "quick" builds set up with Continuous Integration and "full" builds running nightly.

这篇关于TFS构建脚本的SDLC管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！