Tuesday, July 29, 2008

Understand TeamCity Work Flow

首先可以将TeamCity 看作一个专门Continuous Integration(CI)的Web Portal. TeamCity可以管理多个Build Agent, ,每个Build Agent可以认为是专门用来编译代码的机器. 当然Build Agent可以和TeamCity是同一台计算机. TeamCity为什么采用多个Build Agent这样的架构呢?

多个Build Agent的优点:
  1. 主要是考虑到Build代码的过程可能能长, 另外是我们可能又想加入Unit Test的功能, 尤其是Unit Test很多的情况下(或者commit source很频繁), 一台计算机显然不行.
  2. 我们可以将Unit Test按功能分类, 将他们分配到不同的Build Agent上.
  3. 我们也可以将Unit Test按工作量进行分配, 将他们分配到不同的Build Agent上. 这其实是Load Balance
  4. 提供Pre-Tested commit特性, 详见下文.

TeamCity的特点:
  1. TeamCity由Java开发的, 所以是跨平台的, 支持Java和.Net. 它采用Tomcat作为Web Server.
  2. TeamCity支持多种Build工具, Java方面, 你可以选用Ant, Maven, Idea等. .Net方面, 你可以用MSbuild, NAnt以及Visual Studio的Solution文件.
  3. Pre-Tested Commit(Delayed commit)方式: 应该说这是TeamCity杀手级的特性(killer feature). 相信我们都遇到过这样的情况, 有的程序员嫌跑所有的单元测试太费时间, 测试了部分Unit Test就将代码提交到VCS上(或者根本没有跑Unit Test). 结果很不幸, 那些没有测试的case结果却跑不通. 你不得不将代码rollback, 其过程之痛苦不用多言. TeamCity介绍了Pre-Tested提交这个特性, 可以彻底解决这个问题. 它是为IDE提供TeamCity的插件来触发这个过程. 详细流程见下文的TeamCity的一般工作流程.
TeamCity的一般工作流程是(Workflow_Diagram):
  1. Programmer在IDE中通过TeamCity的Pre-Tested commit将代码check in到VCS Server
  2. TeamCity根据其Trigger设置, 定时从VCS Server取代码, 然后将代码发送到Build Agent中. 指派Agent 去执行响应的Build和Unit Test 操作.
  3. Build Agent完成操作后, 将结果返回给TeamCity.
  4. 如果结果正确的话, 则将Code 真正提交到VCS.

No comments: