用 Teamcity 实现 .Net 平台下的持续集成（目录）

2017-09-15 14:37 #JetBrains @持续集成 @C# @.Net @JetBrains @TeamCity

本文是下面一系列文章的总目录，介绍在 .Net 平台上，如何以 JetBrains TeamCity 为工具实现代码的持续集成，也是过去一段时间工作的一个总结。完整的文章目录在最后部分。

前言

我假设你已经了解了持续集成的基本概念。如果没有的话，上面的 Wikipedia 链接可以作为起点，或者阅读 Martin Fowler 大叔的文章，以及同名书籍、该领域的经典著作《持续集成》。

本文及后续的文章中有些地方会将“持续集成”按照社区的惯例简称为“CI”。它们的意思是完全相同的。

.Net 平台上的持续集成方案

CruiseControl.Net

应该是这个领域最老牌的工具了，和很多早期 .Net 开源程序类似，来源于 Java 版本 CruiseControl 的移植。似乎从 2014 年以后就没有再更新过了。

我们早期也曾使用过这个程序好几年的时间。功能基本够用，没有界面，完全靠手工编辑配置文件（有一些第三方的辅助工具）。由于后期活跃度下降，慢慢也就不再使用了。

CruiseControl / CruiseControl.Net 都来自著名的 IT 公司 ThoughtWorks，这家公司在之后又推出了商业性比较强的 Go，现在似乎改名为 GoCD 了，更加强调持续部署（CD）而不仅仅是 CI 的概念。它是用 Ruby 编写的，早期在内存占用和响应速度上声名不佳，我看过评测以后就打消了使用的念头。

Microsoft Team Foundation Server

微软自家的嫡系，曾是独立的产品，现在多归为 Visual Studio 家族的一员。早期版本在安装时很容易出现莫名其妙的问题，且延续了微软一贯的捆绑风格（域控、SQL Server、IIS、SharePoint 等等），产品走的是无所不包的巨无霸式路线。虽然是官方产品，但我个人并不太推荐。如果是微软死忠的话不妨尝试。

当然这个就是本文的主角了。作为 .Net 程序员，即便没有用过，也肯定听说过他们家的 Resharper，而 TeamCity 则是其产品线中相对小众的一款。主要为 Java 和 .Net 项目提供持续集成支持，对 5 人以下的小团队免费使用。由于是不开源的商业产品，所以在社区和插件方面没有下面要说到的 Jenkins 群众基础那么广泛，但聚焦程度高，在产品的细节上比 Jenkins 做的更加细致。我个人认为对没有特殊要求的小型团队来说是很好的选择。

TeamCity 还有很有意思的一点，是它同时提供了代码质量检查工具（Duplidate Checker）和单元测试覆盖工具（dotCover）。这些工具应该是 Resharper 的命令行版本，但也集成在 TeamCity 中，可以在构建项目和单元测试的同时给你一些关于代码质量的报告。它不像专业的工具比如 SonarCube 那样强大和全面，但也是有价值的信息来源，并且开箱即可使用，不需要额外去安装什么，所以也算是一个有特色的亮点吧。

Jenkins

这可能是目前最著名的 CI 软件了，也是很多软件团队特别是互联网公司的普遍选择。最早是从 Sun 公司的 Hudson 产品分裂出来的，但现在无论功能还是社区活跃程度已经超过了 Hudson，而且开发团队很勤奋，经常有新的版本放出。有一个不错的社区，很多人在为它贡献功能和扩展。但繁荣的同时也带来了插件质量良莠不齐的问题。对于 CI 定制性要求比较高，且自身开发实力也比较强的公司建议采用。

除此之外，还有很多基于云的 CI 方案，以及 Facebook、Google 等大公司开放出来的内部 CI 工具。但这些工具和平台大多不太适用于 .Net 平台，这里就不讨论了。

.NetFramework 平台

从我的实践经历看来，.Net Framework 作为持续集成的基础平台是存在一定问题的。按照 CI 的理念，为了最大程度避免环境相关的问题，CI 服务器上除了最基本的编译 SDK 以外不应该安装任何东西。Java 在这一点上做的比较好，服务器上只需要安装 Java SDK 和 Ant/Maven其中之一，基本上不需要别的东西了。而微软的的很多东西却和 Visual Studio 绑在一起，比如中，所有的 Web 项目都存在这样的引用：

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false"/>

这意味着，如果你在构建服务器上只有 .NetFramework SDK 而不安装完整的 VS 的话，很多项目你其实是无法编译的。当然也有一些办法可以绕过这些问题，我也尝试过好几种。但最后还是不得不说，要完整编译解决方案而不想浪费很多时间，最简单的办法还是在服务器上完整安装 VS。而最近的 VS 在工具链的问题上反而越来越退步了，以前 FxCop / StyleCop 都有独立安装包，现在微软却决定把它们集成在 VS 里，直接的结果就是脱离 VS 而构建项目门槛更高了。

当然，如果你用 .Net Core 情况可能会好得多，但我相信大多数现实项目在可预见的未来还是不得不基于 Windows 平台的 .NetFramework。暂且接受这个现实吧。

版本情况

在本文写作时时，TeamCity 最新版本是 2017.1.4，这也是示例所使用的版本。我从 TeamCity 7 就开始使用这个产品，到现在整个构建过程基本上没有多大变化，可以说是相当稳定的，只是在部分细节上有调整。你可以不用太担心内容过时的问题。

系列内容

后续的几篇文章将分别讲述 TeamCity 的安装、配置，并以一个实际例子来说明对 .Net 项目进行持续集成的具体步骤。请按照你的具体需求阅读下面的文章链接。

SHUHARI 的博客