模块化TeamBuilds

Question

我有3个TFS版本(2个开发人员和1个证书)。

我想模块化构建，这样我就不必在每次更改公共项时编辑3个文件。

我遇到的问题是，团队构建只会自动检索Build文件夹(在TeamBuildTypes下)中的项。我可以在构建过程中添加代码来获取其他文件，但到那时已经太晚了。

这是我的场景。我为常见的任务设置了一个“公共”位置。然后，我对该文件进行了更改。因为文件在我的构建过程告诉它下载之前不会下载，所以检索它的时间太晚了(导入已经发生，并且MSBuild进程已经在内存中构造了构建目标)。

我考虑过将其添加到构建的工作区，但随后将在Get Sources目标中检索它(这也为时已晚)。

我找不到一个不让我复制文件或不使用源代码控制的解决方案……

有什么想法吗？

Answer 1

在Team Build 2008中没有“理想”的解决方案来解决这个问题，你最好的选择是将常见的东西放在$(MSBuildExtensionsPath)中的构建机器上，它解析为C:\Program Files\MSBuild，然后从那里引用它们。

如果您的构建配置非常相似，您可以：

将所有生成定义指向单个配置文件夹。

1. 将通用生成逻辑放在TFSBuild.<BuildDefinitionName>.proj.

中不同生成定义的

1. 的底部，并添加TFSBuild.<BuildDefinitionName>.proj.

中不同生成定义的配置

Answer 2

最好的选择是将常见的东西放在构建机器上的$(MSBuildExtensionsPath)中，它解析为C:\Program Files\MSBuild

我不喜欢依赖于“神奇”位置的想法。你最终需要第二次部署+ QA过程来保持你的构建脚本同步...

Team build仅自动检索Build文件夹(在TeamBuildTypes下)中的项。

诚然，这有点差劲，但我在实践中并没有发现这是一个主要的限制。下面是我的TeamBuild文件夹的简化视图：

$/TeamProject
   |- Dev
       |- Module1
       |- Module2
       ...
       Solution1.sln
       Solution2.sln
       |- TeamBuild
            |- 3rdparty
                MSBuild.Community.Tasks.dll
                MSBuild.Community.Tasks.targets
                RandomScriptOffTheWeb1.targets
                ...
            |- SrcSrv                
                srcsrv.ini
                ...
            |- SymStor
                dbghelp.dll
                ...
            Common.targets
            TFSBuild.proj
            TFSBuild.Common.targets
            TFSBuild.Config1.targets
            ...
            UtilityScript1.ps1
            ...
   |- Main           
       ...
       |- TeamBuild
       ...
   |- Release
       ...

所有*.csproj (etc)文件都会导入Common.targets。它导入我所有的第三方任务，初始化各种全局属性/项，并设置引用路径。

TFSBuild.proj导入Common.targets，然后导入TFSBuild.proj，然后通过设置$(BuildDefinition)来导入其中一个配置文件。这样，更具体的总是根据需要覆盖来自不太具体的文件的任务/属性/等。尽管如此，这个简短的文件仍然是我感到有限的地方:以编程方式将构建名称映射到文件名会更好，但MSBuild不允许我根据在运行时目标中设置的属性进行声明性导入。

在大多数情况下，TFSBuild.Config*.targets文件只设置属性；没有“真正”的工作。这些属性包括我想要参数化的团队构建属性，以及控制我的自定义目标(在其他地方实现)将如何工作的其他属性。

按照数量级，TFSBuild.Common.targets是最长的文件。在这里，我用好的默认值配置了所有的团队构建属性，覆盖了像AfterDropBuild这样的目标，并定义了许多我自己的自定义目标，这些目标根据Config*文件中的设置有条件地执行。

注意:我显然已经打开了recursive download option，但这并不是必须的。将构建依赖项分离到子文件夹中更多是为了美观，而不是任何事情。