TFS 构建脚本的 SDLC 管理

本文介绍了TFS 构建脚本的 SDLC 管理的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在为 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

您可以将核心功能分解为包含在所有构建中的通用 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:

如果您对构建脚本进行有风险的更改，请将它们放在开发"或私有"分支中，就像您对任何其他有风险的更改一样.
如果您想要一个仅用于快速验证的构建定义，请在该构建定义导入的 *.targets 文件中将 SkipLabel、SkipWorkItemCreation 等属性设置为 False.

为了稍微扩展 #2，让我们以生产"与测试"构建为例.您只想打开生产版本中的标签等功能.因此，您可以从 TFSBuild.proj 中删除 SkipLabel 属性(如果在那里定义，还有 TFSBuild.Common.targets)，而是在 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 管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！