如何为构建设置 TeamCity -> 测试 -> 部署流程答案

【问题标题】：How to set up TeamCity for Build -> Test -> Deploy flow如何为构建设置 TeamCity -> 测试 -> 部署流程
【发布时间】：2014-04-22 12:54:41
【问题描述】：

我已使用 Git 配置 TeamCity 以获取我的 ASP.NET MVC 项目。

我的解决方案包含网络应用和相应的单元测试：

MY_SOLUTION.sln:

 - WebAppProject
 - SomeCoreLibrary
 - SomeCoreLibraryTests 
 - OtherProjects...

我在 TeamCity 中配置的步骤如下：

使用 NuGet 获取外部包
构建解决方案并进行部署
运行单元测试
运行自动化测试（使用 Selenium）

我希望在构建之后但在部署之前运行单元测试，如果单元测试失败则停止部署。目前部署是在构建之后使用以下命令行参数完成的：

/p:VisualStudioVersion=11.0
/p:DeployOnBuild=true I want this to be done only after SomeCoreLibraryTests.dll unit tests have passed 
/p:PublishProfile=MyWebDeploy
/P:AllowUntrustedCertificate=True
/P:UserName=username_here 
/P:Password=password_here

谢谢，艾诺特

【问题讨论】：

正如所写，很难说出您遇到了什么问题。你能详细说明什么不起作用吗？
我已更改问题标题。我想知道如何构建解决方案，在构建解决方案后运行一些单元测试，然后只有在单元测试通过时才部署构建的解决方案。

标签： unit-testing build msbuild continuous-integration teamcity

【解决方案1】：

我在类似情况下所做的是使用 RoboCopy 将新网站镜像到部署路径中。这不适合你吗？

P.S.：如果您确实做到了这一点，我建议您在 TeamCity 中进行性能改进更改（这将允许您在运行自动化测试的同时运行单元测试）：

我假设您正在为所有这些步骤使用单一构建配置。如果是这种情况，我建议改为使用Dependent Build configurations 来区分不同的问题。你可以在我的一个开源项目中看到一个例子：

http://teamcity.codebetter.com/viewLog.html?buildId=112432&buildTypeId=bt1075&tab=dependencies

以访客身份登录并展开 Testeroids :: Publish to NuGet 树节点以可视化构建流程。

为了实现这一点，基本上你在工件中传递构建步骤的结果（例如，你将生成的二进制文件从 Compile 传递到 Unit Test）。通过使用依赖构建，您可以获得几件事：多个独立的构建步骤可以在不同的代理上并行运行，另外，如果您的构建步骤之一由于外部因素而失败（例如，假设 Publish 由于网络中断而失败down)，您可以再次触发构建，它只会重新构建失败的步骤。

【讨论】：

我真的需要进行 2 次构建配置才能获取构建对象（.dll 等）以进行部署吗？我不能在相同的构建配置中做到这一点吗？另请注意，我没有将 IIS 作为 zip 包部署到 IIS，而是使用发布配置文件进行部署（并且 MSBuild 使用该发布配置文件来部署它/p:DeployOnBuild=true）。我只想在单元测试通过后推迟这个 DeployOnBuild=true 操作。
在将编译步骤与部署步骤分开时，唯一想到的就是深入 MSBuild 目标文件以了解当您说 DeployOnBuild=true 时实际发生的情况。也许您可以通过传递 /target=Deploy 或 /target=Publish 来复制该步骤。您需要查看脚本文件以找出正在使用的确切目标名称。此外，在 TeamCity 中使用一种构建配置而不是 2 种始终是可能的，但我越倾向于依赖构建，我就越觉得这就是他们打算使用它的方式。

【解决方案2】：

我不熟悉您使用的工具。但是，一般来说，我会为一个项目使用一些构建配置：

构建配置，在更改时触发，包含以下步骤：获取最新的源代码和包、构建/编译和单元测试。然后为部署任务创建工件。
构建配置以部署到开发服务器，由成功完成并使用 (1) 中的工件（通过依赖项）触发。
为计划运行频率较低的长期运行（例如集成/功能）测试构建配置。

(2) 的一个优点是，如有必要，您可以重新部署构建/工件，而无需先重建工件。此外，如果您有多个代理，则 (2) 和 (3) 可以相互独立运行。

此外，您还可以标记已通过开发检查的构建 (2)，然后在另一个构建配置中使用其工件将其部署到测试服务器等。

【讨论】：