2022年持续集成工具的选择 .pdf

《2022年持续集成工具的选择 .pdf》由会员分享，可在线阅读，更多相关《2022年持续集成工具的选择 .pdf（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、持续集成 (continuous integration)作为敏捷编程的基石现在已经被绝大多数的开发团队所广泛采用。 而持续集成的工具现如今也是百花齐放，各有千秋， 本文主要对比了在 Java 领域中比较常见的几种CI server （因为公司要求统一整个公司的 CI server ）。如果想了解更多的工具，可以看这里：http:/confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix，这个网页集中了决大多数比较流行的CI server ，但是我发现很多的内容已经落后于实际产品的功能了， 所以如果要对比的话， 可能要实际到

2、产品的站点去看一下，最好还是下载下来运行起来看。在本文中，我主要针对以下几种CI Server 作对比，这也是公司里各个项目组目前自行选用的（版本有点多，国内的多选用了一些open source 的，而老外那边用得比较多的是商用版本，CruiseControl和 TeamCity 是我加的，因为名气非常大。）：CruiseControl (http:/ Hudson (https:/ LuntBuild (http:/ (http:/ AntHill Pro (http:/ Bamboo (http:/ QuickBuild (http:/ 在持续集成领域， OpenSource的 Cruis

3、eControl和 LuntBuild可谓老牌了，尤其是 CruiseControl，出自 thoughtworks ，这可是 Martin Fowler的老巢啊。Hudson作为 OpenSource里持续集成的后起之秀，现在已经赶超了这两个前辈，目前恐怕是使用最多的一个CI Server 了。而后面 4 个是商用的 CI Server ，其中 TeamCity 是来自 jetbrains的，jetbrains是开发著名的 IDE IntelliJ的公司。Bamboo 则是开发著名的Bug Tracking 工具 Jira 和 Wiki Confluence的公司 atlassian公司出品

4、的。 AntHill也属于 Continuous Integration界的元老，QuickBuild则是 LuntBuild的商业版本，我在下面重点考量的是QuickBuild ，因为 LuntBuild好像现在更新较慢了，而且QuickBuild现在好像也有了免费的所谓的 Community Edition ，功能齐全，只是配置数有所限制。在这些商业版本中，TeamCity 应该是目前市场占有率最高的。由于公司里比较倾向使用商业版本的服务器，所以我重点比较的是后4 种，捎带比较了一下CruiseControl和Hudson 。 TeamCity 和 QuickBuild都有各自的免费版本，

5、 有兴趣的也可以去看看。功能对比CI Server 在本质上就是一个定时调度器。我们配置一系列的项目，然后设定一个定时器，让它干一些活，然后通知大家。所以很多公司都使用所谓Home-made名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 7 页 - - - - - - - - - 的工具，用 cron+Ant/Maven 来做持续集成， 这个就已经可以达到CI 的最简单的功能了。而使用工具， 就是我们除了基本的编译和通知功能以外，我们还有很多其它的需求，在我们公司里，选择

6、CI Server主要考虑以下几点：便于公司的统一管理（大约有200+ Projects需要统一管理）对于项目本身进行流程管理: Daily Build - QA Build - Release Build 和公司 AD （Active Directory）的连接以对用户进行权限管理Continuous Testing 的支持，即对于项目的Test 要能产生出详尽的报告以及收集 Test 的统计数据以作为项目的分析和考量Continuous Code Quality Analysis的支持，即能处理项目产生的Coverage 报告， Code的 static analysis报告，并且能收集这

7、些报告的统计数据以作项目的分析和考量与 SCM 工具的集成，我们公司主要有三种VCS ，ClearCase, Subversion和 StarTeam 与其它工具的集成，如bug tracking工具， IDE集成等等。首先，我们从安装的角度来查看一下安装 CI 安装是我们开始的第一步，同时也对各个CI server 都有了初步的印象。按照各自的手册，很快就装好了，我基本上选择的是Standalone 的版本，就是不配置数据库，使用自带的，也不deploy 到 Tomcat或者其它容器，这点，基本上每个CI Server 都非常简单。所以也没看出什么好坏来。这里不得不提一下AntHill，有点

8、小家子气，要download 还得提交一个 request ，然后才能下载，安装，有点烦。配置项目在大多数的 CI Server 中，绝大部分都是以Project或者 Project Group来进行管理，只有 LuntBuild和 QuickBuild比较另类，它们使用了Configuration这个术语，意即一个配置。 在配置一个典型的项目的时候，即只处理基本的一个流程：CheckOut, Build, Publish Artifacts，这些工具都完成的非常好，也非常简单，我使用下来，觉得TeamCity 的导航最方便，一目了然。而LuntBuild和QuickBuild在这方面稍显人性

9、化不足，这两个工具都没有使用wizard 的模式。下面，我接着实验配置50 个测试项目，这也就开始考验一个CI Server的管理能力了（因为我们项目较多）。使用下来，我发现QuickBuild对于我而言，最实用。因为它使用Configuration而不是 Project ，并且 QuickBuild是这些 CI 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 7 页 - - - - - - - - - Server 中唯一支持树状结构配置的。我可以把Configurat

10、ion配置成 Team A, Team B . ，然后根据实际情况，对每个Team配置任意多个子节点，孙节点（注意，Configuration的数目在 QuickBuild的 Community Edition里是要限制的，好像是最多 16 个），另外， QuickBuild 的继承关系使用起来也非常方便，如果要管理一个大型的CI Server ，没有这种继承对我而言简直是一种折磨。比如说用 hudson 来配置 50 个项目，我折腾了大半天，而用QuickBuild来，我大约只用了一个小时，我实际配置的Configuration（含有实际 step 定义的）只有 3个，其它的都是继承下来，

11、然后修改了一下参数而已， 而如果我们需要批量修改一系列的 configurations的时候，则由于有继承关系，通常我们只要去修改一下父节点的设置就可以了。TeamCity 支持 Project Group的概念，类似于一种树形，但是还不完备，它只能分成两级关系，即Project Group和 Project 。另外 QuickBuild所拥有的继承的功能，在别的CI 里没有看到过，有的只是象TeamCity 类似的 copy project的功能。而 QuickBuild在复制的能力上远远胜过其它的 CI Server ，它可以整个子树拷贝，这也就意味着，我可以配置一个公司用的 templa

12、te configuration树，然后复制出 A部门，B部门， C部门，等等等等。对于不同项目之间的区别则通过变量来控制，赞一个！TeamCity 在配置的方便上真得是没话说，非常直观，最酷的是象JUnit ，NUnit 这样的 Tests ，连 Ant 脚本都不需要写了，它直接就可以找出项目里的unit tests，这个在其它的工具里也没有看到过。 至于 CruiseControl，Hudson ，Bamboo 等则是中规中矩，无甚亮点。这个环节，QuickBuild和 TeamCity 胜出。另外配置一个项目要配的就是项目持续集成的流程管理，在我们这里，基本上是这样一个流程 : Dail

13、y Build - QA Build - Integration Build - Release Build 。所谓 Daily Build，顾名思义，就是每天一次的，由development team管理以保证项目的顺畅执行，然后经过一段时间后，development team 要提交到 QA那边进行测试，通常是2 个星期到一个月左右，随项目大小不等，QA测试结束之后，如果没有重大的问题，则提交作Integration Test，以保证在模拟的实际环境中能正常工作，最后，如果没有什么问题的话则作Release Build以形成发布版本。对于公司里有一些Team使用敏捷编程的，则需要增加所谓的

14、Commit Test Build，也就是 developer 在作每一个 checkin 的时候自动触发一个 build ，以保证 build 不会被这个 checkin 破坏（包括不会破坏unit tests和 code quality)。这也是所谓的要作continuous testing和 continuous code quality analysis，这些都是通过利用JUnit, NUnit，CheckStyle, PMD ，Cobertura ，FxCop等工具来实现的。我们在后面也会讲到，这里略过。这个环节里，个人比较喜欢AntHill Pro和 QuickBuild ，这两个

15、工具都是比较强调流程的，尤其是 AntHill Pro更是将其作为卖点。 AntHill Pro以工作流的模式来定义这个流程，一个项目可以定义多个的workflow ，对应于我们的case，就是定义 Daily Build的 workflow ，定义 QA Build 的 workflow ，等等，然后在作promote 的时候，通过选择不同的workflow 来达到目的。而 QuickBuild则是利用已有的 configuration的概念，定义不同的Configuration，然后在Configuration的 setting里定义一个或多个要promote 的 configuratio

16、ns。 要作 promote 的时候，则通过点击某个 build的 promote 按钮将其 promote 到指定名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 7 页 - - - - - - - - - 的 configuration上去，也很方便。使用 AntHill的模式，概念上很清晰，因为我们要作的是流程管理嘛， 所以 workflow 会听起来比较容易接受。 而 QuickBuild则是把它绑定在 Configuration上，使用起来比较简单，但是找起来要费

17、点事，至少对于我而言是这样。Hudson也有类似的流程管理，但是它是自动的，而promote 在我们这里是需要人来作review 的，也就是说要人去参与，判断究竟使用哪个版本来 promote，所以在我们这里，不是很合适。在配置项目这个环节里，个人感觉QuickBuild比较灵活，既可以做到很简单的配置，也可以做到非常复杂的配置，而且配置起来方便性非常好。只是术语与其它的 CI Server有些不同，需要熟悉一下。Build 功能CI Server 最重要的就是 Build 本身的功能， 包括 SCM 的连接，用户的权限管理，Build 工具的支持。首先我们来看看SCM 的支持。SCM 支持在

18、这些 CI Server 中，AntHill Pro 和 Hudson支持的种类最多，尤其是Hudson ，基本上市面上的 SCM 都有所支持。对于象比较常见的Subversion ，CVS ，ClearCase，StarTeam，SourceSafe 等，各家都已经支持了。而在上一项目中表现较好的 QuickBuild ，则属于在 SCM 里支持最少的一家， 它还不支持 git ，Team Foundation Server，这个目前已经很流行的两种SCM ，实在有些遗憾。不过瑕不掩瑜， QuickBuild 在支持 SCM 的时候，由于使用变量的支持，却是多家CI Server 中最灵活的

19、一家， 它可以使用变量来配置SCM 的 URL ，而其它的， 则是通过定义一个基本的URL ，然后针对不同项目来定义各自的SCM repository 。而QuickBuild还有一个它自有的QuickBuild Repository，用于在不同的Configuration中传递 artifacts，实际用起来也很方便，比如说我们在一个项目里要用到别的项目的artifacts， 那么就可以定义一下这个repository。 当然，这个功能也可以通过Maven的 repository来完成来达到相同的目的。TeamCity也提供了类似的机制， 只不过 TeamCity的 Repository其实

20、就是一个 Ivy 的扩展。SCM 的数据在这些 CI Server 中都有体现，从每一个Build 的 change sets 到历史统计。说明现在大家都很重视对于这些数据的收集和分析。其中TeamCity 能直接从 Web页面上直接调用 IDE 来打开这些改动的文件是一大亮点，毕竟是做IntelliJ的公司啊！名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 7 页 - - - - - - - - - 用户管理这个基本上是每个CI Server 的必备功能了， 基本上都是

21、既可以用内置的数据库管理（Hudson好像没用数据库），又可以连接LDAP 服务器。我只是简单测试了一下，没有深入，也就没有什么发言权了。Build 的 Dependencies 管理 (Dependent Builds) 在实际的项目中，我们常常会出现项目之间的依赖关系，比如说A项目依赖于 B项目，B项目依赖于 C项目。所以当我们要编译A项目的时候，我们需要先编译C项目，然后编译 B项目，最后再来编译A项目，这样做的好处显而易见，就是保证我们总是使用最新开发的code 来编译一个版本，如果发生了什么问题，我们也可以很容易的知道究竟是哪个项目break 了整个 build的流程。这个功能基本上

22、所有的这些 CI Server都有提供，而能力各有千秋。TeamCity 在这里属于最弱的一个，它只能通过定义Ivy 来达到 Artifacts在不同项目中的依赖管理，而 AntHill Pro， Bamboo 和 QuickBuild则都有提供两种类型的dependency 管理，即 artifacts和项目本身的依赖管理。不过TeamCity 却有另外的杀手锏，就是导入项目的功能，它支持从IntelliJ的项目， Maven的项目中直接导入创建这种依赖关系。分布式 Build Pool 由于公司的项目繁多，平台繁多，对于一个项目需要分布到不同的平台去编译，测试，这时候就需要建立一个Buil

23、d Pool了，基本上上述各家的CI Server都已经支持了这种分布式的build pool，其实质是利用了 grid computing技术来进行管理。也就是一个build server带上一群的 build agent，然后把 build的任务分布到不同的agent 上去执行。在这里不得不再赞一个QuickBuild了 （呵呵，这个 QuickBuild好像给人惊喜不断啊） ，其实 QuickBuild的 agent 与其它家的倒没什么不同，只不过就是一个computing unit ，关键在于 QuickBuild里配置一个 configuration，它使用了 step 的概念（这个

24、 QuickBuild的术语倒是不少嘛），这个 step 在 AntHill Pro 里也存在，关键在于这个step 是可以分布的，也就是说，我配置一个项目的时候，可以定义一系列并行的分布式的step ，这样对于管理和收集artifacts非常方便，我们可以定义 Test On Windows, Test On Mac, Test On Linux，然后设置一下运行这些step 的时候需要什么类型的agent ，QuickBuild就可以把这些任务分布到这些平台的agents 上去运行了。而其它家的可能是因为收费的方式，象 TeamCity，一个 build只能在一个 agent上运行，我如果

25、要做到同样的效果， 就需要定义出三个项目， 然后让这三个项目在不同的 agents 上运行，最后，还要再定义一个项目，让这个项目去收集它们的 artifacts，非常麻烦。 Bamboo 和 AntHill也类似于 TeamCity。而 Hudson在这块的能力很弱，个人感觉不如其它的产品强大，而且使用起来也更复杂一些。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 7 页 - - - - - - - - - Report 功能和统计上述各家 CI SERVER 都提供了

26、 Report 的功能和统计的功能，在这个领域里，Hudson毫无悬念的是支持报告类型最多，最全的（谁叫咱OpenSource呢，有的是人开发）。 Bamboo 属于支持报告类型最少的，不过也有很多第三方的plugin供选择。 我们所关心的几个reports都有被各家支持，其中 QuickBuild 的 report给我的感觉最华丽，不过好像是参考google analytics来的，从界面上看和analytics简直就是一个翻版。在使用上，QuickBuild和 TeamCity 的最方便，直接点报告中的链接就可以作一些过滤。在统计信息方面， 各家对 tests的统计都非常完备，这也从一个侧

27、面反应出test driven现在那是深入人心啊。在支持Test Driven 方面， TeamCity 是力拔头筹，得益于开发 IntelliJ的经验， TeamCity不仅可以自动寻找出项目中的unit tests（你不用在 Ant 脚本里调用 junit task ，或者在 Maven里调用 surefire），而且对于上次运行失败的test cases，它可以在下次 build中自动先运行，这样就可以避免一个build运行了很久才发现上次失败的 test还没有被更正过来呢，强！另外，要提一下的是QuickBuild中那个 Build 的 Dashboard 我非常喜欢，对于一个项目当前

28、的状况可以一目了然，有多少个 tests 成功了，多少失败了， 多少被 fix了，多少还没有 fix ，总之，信息很丰富，不过就是配置起来有点复杂，需要我去一个报告一个报告去加step ，如果能做到 TeamCity 的程度，简直就是完美了。对于其它的 CI Server 则是亮点不多（其实也很强，只不过是对比而言，我觉得TeamCity 和 QuickBuild 更强，更好）。与第三方工具的集成在与第三方工具的集成中，Hudson遥遥领先，是所有CI Server 里 Plugin 最多的。可以和 FaceBook ，Google Calendar ，Twitter ，反正基本上你能想到的，

29、它都有。不过对于我们而言，好多Plugin 没有太大的价值。 Bamboo 在与它自己的几个产品中集成度也非常好，比如说Jira ，Wiki ，Clover 等。这几个我们公司都有用到，在这点上非常理想。价格名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 7 页 - - - - - - - - - 不得不考虑一下价格的因素，好像记得有人说过，Price is nothing, but price is everything，尤其在这个金融危机的年代里。这点，勿庸置疑，Op

30、enSource永远是最好的。而在商用的这几个里QuickBuild最便宜，它使用的是Site License ，一个 Site 收$2999，AntHill最贵，我询问了一下，按我的配置，随便搞搞就要 $10000了，TeamCity 的入门也很便宜， $1999带 3 个 agents ，可是针对我们的情况，算了一下也要上$8000了（它是按 agent 收费的）， Bamboo也很贵，按照它的功能而言，我觉得性价比不是很好。总结综合各方面因素的考虑，我们最终选择了QuickBuild ，虽然这个产品名声不是很大，不过想想它的客户中，不乏象Cisco ，HP这样级别的公司，应该还是可以值得

31、信赖的吧。 另外就是我们使用下来觉得它还是拥有诸多亮点，对于我们的统一管理来说， 可谓是方便至极。 另外价格方面考虑也很不错。当然如果你的团队不是很大，那么选择QuickBuild的 Community Edition和 TeamCity 的Professional Edition都是非常值得的，这两者都是免费的，而且QuickBuild的 Community Edition功能没有任何裁剪， 只是限制了一下 configuration的数目，非常适合要求比较高而项目不是很多的团队。好了，有太多太多需要讨论的东西了，CI 这个领域现在还处于高速发展阶段，本文纯属探讨，欢迎大家拍砖。由于时间有限，对每个产品了解的不是很深入，错误在所难免，如果我有什么地方不是很准确，也欢迎告诉我。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 7 页 - - - - - - - - -