用 Teamcity 实现 .Net 平台下的持续集成（目录）
本文是下面一系列文章的总目录，介绍在 .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 等等），产品走的是无所不包的巨无霸式路线。虽然是官方产品，但我个人并不太推荐。如果是微软死忠的话不妨尝试。
JetBrains TeamCity
当然这个就是本文的主角了。作为 .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 项目进行持续集成的具体步骤。请按照你的具体需求阅读下面的文章链接。
全文目录
- 用 Teamcity 实现 .Net 平台下的持续集成 - 目录 (本篇)
- 用 Teamcity 实现 .Net 平台下的持续集成 - 安装
- 用 Teamcity 实现 .Net 平台下的持续集成 - 配置
- 用 Teamcity 实现 .Net 平台下的持续集成 - 构建