在进行持续集成时如何处理多个 Visual Studio 配置？答案

【问题标题】：How do I handle multiple Visual Studio configurations when doing continuous integration?在进行持续集成时如何处理多个 Visual Studio 配置？
【发布时间】：2011-04-20 09:11:17
【问题描述】：

我在 Visual Studio 中设置了多个配置，以便我可以为多个客户之一构建一个解决方案（包含多个项目）。少数 web.config 设置是根据客户定制的，并且代码构建到不同的“BuildDir”，因此我可以将其打包并交付。目前，这一切都是由我的开发机器上的 Visual Studio 配置管理器以及几个 Web 部署项目驱动的，我发现它非常脆弱。

我想实现一个 CI 服务器（CC.Net 或 TeamCity），但不确定如何最好地适应这种每个客户端的配置（或者我是否应该尝试）。我在一个分支中开发，并在每个功能完成后与主干重新集成。我认为 CI 服务器应该在主干中集成代码是否正确，如果是，我该如何处理每个客户的调试和发布版本？

我的配置是：

开发（调试）
测试（调试）
UAT - 客户。 1（发布）
生产 - 客户。 1（发布）
UAT - 客户。 2（发布）
生产 - 定制。 2（发布）
等

除了每个客户的少量配置设置之外，所有客户的产品几乎都相同。

我很想听听您对我如何设置它的想法，或者我是否在考虑这个错误？

谢谢。

【问题讨论】：

在trunk中集成代码是什么意思？我认为为客户构建的构建必须仅在发布中构建。他们只想看到产品——而不是未处理异常的细节。如果您想在分支中使用新功能进行调试构建，请对您的存储库进行两次不同的签出。第一个是主干 - 对于客户，第二个将位于您的分支机构并使用您正在开发的功能构建产品。我认为客户不会希望看到部分工作的错误功能。
我同意你的看法——也许我的解释不是很清楚。我的客户只看到发布版本。我在本地为 Dev 生成一个 Debug 构建，为 Test 生成一个 Debug 构建（使用不同的连接字符串等）。我在一个分支中使用 dev 功能，并在完成后重新集成到主干中。因为该软件对所有客户都是相同的，所以我想我会在主干中的代码上使用 CI，然后“它”（CI 或其他东西）可以整理 web.configs，然后为我的不同的客户。这听起来像下面@andriy-k 的建议。

标签： visual-studio-2010 msbuild continuous-integration

【解决方案1】：

我们遵循两步构建过程：第一个解决方案是使用 Debug/Release 配置正常构建。接下来（在构建完成过程之后），运行转换 web.configs 的任务（如果是一个文件，但可以轻松修复以处理一堆文件）：

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>
<Target Name="TransformWebConfig">
    <TransformXml Source="$(WebFolderName)Web.config"
        Transform="$(WebConfigsFolderName)Web.$(WebConfiguration).config"
        Destination="$(WebFolderName)Web.config" />
</Target>

这边
1) 解决方案文件中只有两个有意义的配置
2) 在构建服务器上，您传递两个属性：配置（例如发布）和 WebConfiguration（例如 UATCust2）
3）这个任务只在构建服务器上运行，因为它是更大的构建脚本的一部分：开发人员总是使用默认的调试/发布配置，目标平台配置可以单独存储，例如在存储库的受保护部分中，甚至在网络共享中。

【讨论】：

【解决方案2】：

我使用UppercuT、RoundHousE 和 CC.Net 解决了这个问题，并通过更改我在 SVN 中分支和标记各种配置的方式。现在我有一个由 CC.Net/UppercuT 在构建服务器上自动构建的“主线”代码（主干），然后可以使用 UppercuT 进行打包和部署。如果我需要构建特定客户的源代码，我可以获取他们的源代码，进行必要的更改，然后提交回他们的分支。在该分支中运行 UppercuT 然后为该客户生成一个可部署的包。 UppercuT 和 NAnt 的结合为 IMO 提供了比使用 VS2010 的配置管理器更大的灵活性。

【讨论】：