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

Question

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

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

我的配置是：

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

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

我很想知道你对我如何设置这个的想法，或者我的想法是否错误？

谢谢。

Answer 1

我们遵循两步构建过程：第一个解决方案是使用调试/发布配置正常构建。接下来（在构建完成过程之后），运行任务来转换 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) 此任务仅在构建服务器上运行，因为它是更大构建脚本的一部分：开发人员始终使用默认的调试/发布配置，目标平台配置可以单独存储，例如存储在存储库中的受保护部分中，甚至存储在网络上分享。

Answer 2

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