当前位置：文江博客话题详情

TFS 构建脚本的 SDLC 管理

发布于 2024-07-27 01:05:58 字数 230 浏览 9 评论 0原文

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

您是否设置独立于生产构建服务器的开发和质量控制环境？是否有其他方法将脚本开发过程与构建过程的其余部分隔离，以便开发中的构建脚本不会干扰“生产”构建？

Team Build 喜欢创建工作项、更新工作项并添加标签作为构建过程的一部分，而我不希望在“测试”构建中发生这种情况。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

剩余の解释 2024-08-03 01:05:58

在这里查看我的答案：模块化 TeamBuilds

您可以将核心功能分解到包含在所有内容中的通用 MSBuild 文件中构建。此外，所有这些文件都是更广泛的分支结构的一部分，因此它们直接参与您预先存在的 SDLC，无需任何额外的工作。因此：

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

为了稍微扩展一下#2，让我们以“生产”与“测试”构建为例。您只想在生产版本中打开标签等功能。因此，您可以从 TFSBuild.proj（以及 TFSBuild.Common.targets，如果它在那里定义）中删除 SkipLabel 属性，并将其设置在 TFSBuild.Production.targets 和 TFSBuild.Test.targets 中——当然，使用两个不同的值。

正如前面的问题中提到的，TFSBuild.proj 是主 msbuild 文件，用于控制构建的其余部分如何运行。这是我的样子：

<?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 启动的构建定义。我自己，我通过持续集成设置了“快速”构建，并且每晚运行“完整”构建。

Check out my answer here: Modular TeamBuilds

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:

If you're making risky changes to your build scripts, make them in a "dev" or "private" branch, just as you would with any other risky changes.
If you want a build definition that's just for quick validation, set properties like SkipLabel, SkipWorkItemCreation, etc to False in the *.targets file imported by that build definition.

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.

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>

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.

回复收藏 0 原文

~没有更多了~