初创公司应该如何做好持续集成和部署
初创公司应该如何做好持续集成和部署？前言持续集成和部署是每一个互联网开发团队都必须要面对的问题，特别是在初创公司，由于业务和技术团队快速增长，技术积累较弱，所以一个高效的，可持续的运维规范尤为重要。最近一段时间，一直在梳理项目开发流程以及自动化测试和部署规范，作为一个总结和大家分享，希望有所帮助。高效可持续的运维环境需要合理的规范作为支撑：?????应用管理规范权限管理规范配置变更规范发布策略规范日志运维规范持续集成部署实战(该内容将在后续文章中进行讨论，本次不展开)一、应用管理规范1.应用版本化
& 果果文库所有资源均来源于互联网，仅供网友学习交流，若侵犯了您的权益，请联系我们予以删除。
8960&&人浏览
5485&&人浏览
4784&&人浏览
1029&&人浏览
17863&&人浏览
17418&&人浏览
10905&&人浏览
7255&&人浏览
9257&&人浏览
14265&&人浏览
2189&&人浏览
17175&&人浏览
12094&&人浏览
4159&&人浏览
5729&&人浏览
本文标题：初创公司应该如何做好持续集成和部署 链接地址：
copyright@ 2013- Inc. All Rights Reserved 果果文库 版权所有 联系站长: ; 经营许可证编号:浙ICP备号谈谈持续集成，持续交付，持续部署之间的区别 - 简书
谈谈持续集成，持续交付，持续部署之间的区别
经常会听到持续集成，持续交付，持续部署，三者究竟是什么，有何联系和区别呢？
假如把开发工作流程分为以下几个阶段：
编码 -& 构建 -& 集成 -& 测试 -& 交付 -& 部署
正如你在上图中看到，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期。
持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程（XP），是 XP 最初的 12 种实践之一。
CI 需要具备这些：
全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要；
灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折；
版本控制工具。如 Git，CVS，SVN 等；
自动化的构建和软件发布流程的工具，如 Jenkins，；
反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。
持续集成的优点
“快速失败”，在对产品没有风险的情况下进行测试，并快速响应；
最大限度地减少风险，降低修复错误代码的成本；
将重复性的手工流程自动化，让工程师更加专注于代码；
保持频繁部署，快速生成可部署的软件；
提高项目的能见度，方便团队成员了解项目的进度和成熟度；
增强开发人员对软件产品的信心，帮助建立更好的工程师文化。
持续集成，该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统，关键在于团队运行的基础设施，团队对持续集成系统的资源投入力度。
对比一下私有部署和托管型持续集成系统，或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中，需要提供多台服务器来完成 CI 系统的运转，同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ，他们的特点是自由开源，且文档支持广泛。优点在于对构建环境有完全的控制权，能够实现完全定制。但需要搭建环境和配置、维护成本高，需要买专门的机器，花费较多人力物力且更新迁移风险高；
Hosted CI 指的是由 SaaS 型的 CI 服务，全程在线进行构建配置，不需要考虑装机器，装软件，环境搭建等成本。常见的有 CircleCI，Codeship 和 TravisCI 等，还有国内最新的持续集成服务—— 。SaaS 型的 CI 的特点在于无需额外机器，几分钟就可以用起来。可以根据你的需要动态调度资源。省时，省心，省力。
整体而言，Jenkins 过去一直是大部分公司的选择，但这个现象正在发生改变，随着公有云服务、Docker，SaaS 的普及，越来越多的企业开始选择 Hosted CI，也就是托管型持续集成系统。
另外，在选择合适的持续集成服务时，还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
选择持续集成系统只是持续集成应用的其中一步，还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成，可为持续交付与持续部署打好坚实基础。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。
试想想，如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。当然，持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。
持续交付的好处
持续交付和持续集成的优点非常相似：
快速发布。能够应对业务需求，并更快地实现软件价值。
编码-&测试-&上线-&交付的频繁迭代周期缩短，同时获得迅速反馈；
高质量的软件发布标准。整个交付过程标准化、可重复、可靠，
整个交付过程进度可视化，方便团队人员了解项目成熟度；
更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
为什么说持续部署是理想的工作流程？
“开发人员提交代码，持续集成服务器获取代码，执行单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转。”
实际上，产品在从需求到部署的过程中，会经历若干种不同的环境，例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，产品在不同环 境中的具体部署，状况是比较非常复杂的，从头到尾地全自动持续部署的确困难。那么，如果能做到持续交付，保证代码在模拟环境没问题，也许团队成员做到真正的心理有数。
持续部署的优点
持续部署主要好处是，可以相对独立地部署新的功能，并能快速地收集真实用户的反馈。
“You build it, you run it”，这是 Amazon 一年可以完成 5000 万次部署，平均每个工程师每天部署超过 50 次的核心秘籍。
「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
欢迎分享你的观点。
【参考文章】
fir.im 专注开发测试效率提升，为开发者提供 App 测试托管分发、实时崩溃分析、持续集成等产品与服务。您的位置： >>
　　在中，我们讨论了如何在代码变得庞大，组件增多的情况下，做好外部库和内部组件依赖管理，从而提高构建效率。可以应用的实践包括：一次生成，多次复用；建立统一制品库，外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理；对架构进行调整，使一个大的代码库分成多个组件；每个组件有自己的持续集成体系；对多个组件做持续集成。然而，解决一个问题后，总会有另一个问题等在那里，需要你来解决。这次Joe的团队遇到了部署问题。
　　星期一早上，Alice一进办公室，就看到一脸倦意的Joe坐在椅子上，喝着咖啡。
　　&今天怎么来得这么早？看样子，你没睡好啊？&Alice问道。
　　&当然啦，昨天晚上我就来了。&Joe无精打采地回答道。
　　&怎么啦？&
　　&还不是因为新版本上线出了点儿问题&，Joe说道。&看来我们要把部署这件事好好讨论一下，再这样下去，不只我要来，你们也要和我一样啦！呵呵！&
　　当天下午，Joe邀请了运维团队的主要负责人Tom和Steven，召开了一个关于部署问题的讨论会。
　　Joe说道：&先请运维部门的Tom介绍一下上周末的新版本上线过程和发现的问题吧。&
　　Tom描述了上线部署全过程。
　　不可重复且不可靠、易出错的手工部署过程
当新版本开发测试完成后，由开发团队的成员在浏览器上登录运维平台，填写上线申请单。申请单的内容包括新版本的上线部署步骤。
测试人员为了保证能够升级部署成功，首先要复制生产环境中的程序和数据到本地的测试环境中，然后根据上线申请单中所描述的上线部署步骤进行操作，对上线步骤进行验证。
运维人员登录到运维平台，收到上线申请单后，确认&已收到&。
运维人员发现上线部署步骤有问题，生产环境的路径与上线部署步骤中描述的不一致。于是与开发人员进行沟通，让开发人员修改上线部署步骤。
开发人员修改后，再次通知测试人员和运维人员查看并确认。
确认无误后，运维人员根据部署计划，登录到生产环境中，依照上线部署步骤，手工操作完成。
　　&上周末上线部署时出现的情况是：在本次部署之前，我们的集群中，有两台机器因HotFix，其程序配置被修改过，与其它机器不一致。因此，该机器上的部署失败，导致部分服务不可用。运维人员查了很长时间没有发现问题，星期日打电话把Joe叫来帮助我们查问题时，Joe才回忆起有那么一次HotFix，但当时负责的运维人员已经离职，没人其它运维人员知道这件事情。&Tom说道，&我们对问题进行了分析，认为应该加强我们的上线流程管理，对于那种HotFix也应该发起一个审批流程，并且在该流程中不但要主要负责人审批，而且要对相关人发出周知通报。另外，我们的运维人员应该对上线单进行严格审核，并对部署中所涉及的机器进行更详细的验证，对生产环境中的任何修改都要进行登记。即使非常紧急，也要在事后补充记录一下。&
　　&这些方法固然很好，但其实我们可以采用更好的办法来解决。&Joe接着说到，&假如我们在部署运维工作也能够借鉴持续集成的做法，利用一些最佳实践，那么这次部署事故根本就不会发生。比如（1）将部署操作脚本化；（2）进行持续部署验证测试；（3）部署脚本通用化，环境变量等使用配置方式传入；（4）让测试环境尽可能与生产环境一致，至少在成本条件允许的情况下尽量保持相似；（5）对环境配置进行版本控制；（6）任何人不得直接对生产环境进行直接的手工操作，等等。&
　　将部署操作脚本化，并进行部署验证测试
　　Bob说道：&嗯，其实那些上线步骤中所描述的内容都可以进行脚本化，之前也讨论过这一问题。目前上线步骤中的内容基本都可以写成自动化脚本，即使现在不行，也可以通过少量改造，使其可以自动化。但问题是... ...&Bob犹豫了一下，接着说道，&如何来验证这些脚本是正确的呢？&
　　Joe 说道：&保证运维人员是如何验证上线申请单上的上线步骤是正确的呢？同样，我们也可以做一些部署验证就行了。这些部署的验证也可以通过脚本方式来进行，比如在安装之前验证程序所用端口没有被占用，安装之后验证该端口已被该程序所使用；比如安装之前验证程序日志中记录了该程序已停止运行，在安装之后验证程序日志中刻录该程序已重新启动；等等&。
　　Alice问道：&那我们还要调试这些部署脚本呀？没有线上生产环境，我们怎么调试呢？&
　　各类环境尽可能相似，并使部署脚本通用化
　　Joe 回答道：&首先我们应该加强基础设施这方面的投入。在力所能及的情况下，让测试环境与生产环境相似。比如，生产环境可能有100台机器的集群，那我们至少要找两台机器的集群做测试环境。生产环境中使用Tomcat，我们的测试环境和开发环境中也应该使用相同的Tomcat，而不用Jetty。&
　　Joe 停下来，喝了一口咖啡，接着说道：&这样一来，我们的部署脚本就可以在开发环境、测试环境进行测试了。当开发人员进行本地测试时，可以使用这个脚本进行单机的部署。当测试人员进行集成测试时，可以使用同样的脚本进行多机部署。与机器数量无关的配置可以统一放在某配置文件中。而与机器数量等相关的配置可以放在另外的配置文件中。由于在真正上线部署之前，开发人员和测试人员已经使用同一个脚本进行多次部署，就是对该脚本进行的测试。当我们上线部署时，只有与机器相关的配置文件会有变化，其它配置基本相同，所以上线部署时脚本出错的几率已经比较小了。而且，这种自动化没有人工干预，也不会发生手工误操作。&
　　Tom问道：&那这些脚本由谁来写？由谁维护呢？&
　　Joe回答道：&谁最了解情况，就由谁来写。其实，我们也应该像对待产品代码一样，来对待这些脚本和配置文件，把它们放在我们的代码库里，进行版本控制。无论是运维人员还是开发人员，或者测试人员，对这些脚本的修改都应该提交到版本控制库中，除非他所做的修改只是为了测试他自己在本地的程序，那就不用提交了。这样一来，&谁在什么时候对什么进行了修改，为什么做修改？&这个审计问题就可以直接由版本控制系统来回答，也就做到了所有内容可追踪了。&
　　对环境管理进行版本控制，杜绝对生产环境的手工直接修改
　　&听上去，对于配置文件、脚本等进行版本管理的确是解决了运维部署的很多问题。但如何对环境管理进行版本控制呢？&Tom问道。
　　Joe想了想，说道：&环境管理比较复杂。一般来说，环境包括几个层次，包括硬件及网络配置、操作系统、我们的应用程序所依赖的软件堆栈及其配置、以及我们的应用程序运行时所需的数据及其配置。目前对我们来说，对于硬件及网络配置、操作系统这两层来说，有两种方式进行管理。一种是利用一些专用软件进行自动化的远程配置，即只要给机器加电，就可以通过一些技术对一台机器进行系统的安装与配置。另一种是使用虚拟化技术来进行系统配置管理。对我们现在的游戏平台来说， 使用后者即可。只要将基本的环境做成虚拟机镜像文件，并将其作为环境基线进行版本管理。当然，由于镜像通常较大，所以最好不要使用常见的版本控制工具（如subversion，Git等）进行，而使用某种简单的机制即可。&
　　Joe停了一下，看看大家没有提问的意思，于是接着说道：&至于基于其上的软件堆栈及堆栈中各软件的配置管理完全可以利用类似于CfEngine，Puppet或Chef的工具进行。这些软件环境管理工具都提供某种领域专属语言来描述软件堆栈配置，并保存在文本文件中。这些工具一般通过服务器/客户端的工作方式运行，客户端向服务器发送请求，验证本机器节点的软件配置是否与服务器中的设置相符，如果不符，就会自动更新。尤其重要的是，这些更新操作都是幂等的，即无论这些配置在该客户机上执行多少遍，每次的结果状态都是相同的。另外，它们通常能与版本控制工具集成。所以，只要将我们的软件堆栈配置管理信息放到版本控制库中，就可以同时管理数台机器。&
　　&oh, 对不起，Joe，我想打断一下，&Tom问道：&你能画一个图来解释一下你刚才所说的这种软件环境配置管理工具吗？&
　　&当然没问题。&Joe拿起笔在白板上画了一个Puppet的工作示意图，如下图所示。
　　&看上去清楚多啦。&Tom笑道，&通过这种方式，我们就只需要将版本控制库中保存的配置信息签出到本地，进行相应的修改，再提交到版本控制库中，这种工具就会自动帮我们完成必要的配置更新了。是这样的吗？&
　　&对，&Joe点了点头，说道，&如果我们的部署脚本也是通过这种方式来做的，那么我们就根本没有必要登录到生产环境的机器上，进行手工操作了。而且，Puppet还提供一种Try Run功能，可以进行配置变更的模拟，让你能够对比一下变更前后的不同之处。&
　　Tom说道：&你说的这些听上去都不错。但并不是所有人都能够修改生产环境的配置信息的。所以我们还是需要一个软件平台来管理上线的申请审批流程。&
　　&在任何企业中，这种申请审批流程和生产环境变更的授权都是必要的，但这仅仅是审核流程的操作。而真正与软件部署相同的具体操作都不应该在这种审批流程当中。&Joe回答道。
　　Tom接过话来，说道：&嗯，这样的话，我们仍旧能够做到：有权限的人才能真正修改生产环境的配置文件，同时达到了无人真正直接操作生产环境的目的，避免了手工误操作带来的问题。&
　　参加本次会议的测试人员和运维人员对这种做法产生了浓厚的兴趣，并要求开发人员给予配合，将目前游戏平台的部署自动化。Tom说道：&这就是我们运维工作的一个方向。让枯燥易出错的重复性手工操作变成受控的自动化，从而解放运维人员，让我们可以关注于更加有价值的运行监控等工作中。&
　　Alice说道：&这看上去还是有一定的工作量啊。&
　　&当然，我们可能需要做一些工作，但我想这些投入是值得的。&Joe回答道。&同时，还需要各种角色之间更紧密的配合，而不是像之前那样，通过一个代表上个世纪八十年代先进技术的办公自动化平台来描述部署上线步骤这类关键的业务操作信息。&
　　Tom也点了点头，说：&嗯，应该使用版本控制方式。但我们还是需要一个上线审批的流程，只不过，这个流程中不再保存上线步骤这类与实际部署相关的业务信息，而只是为了部署人员的资格审核与信息周知的目标。&
　　经过一番讨论，开发、测试和运维团队在这件事情上达成了一致，并按计划开始实施了。
　　需要注意的是，他们似乎没有谈到数据管理。他们会遇到相关的问题吗？
软件工程热门文章
软件工程最新文章CI（continuous integration）持续集成
一次构建：可能包含编译，测试，审查和部署，以及其他一些事情，一次构建就是将源代码放在一起，并验证软件是否可以作为一个一致的单元运行的过程。可以理解为频繁的在多个团队的工作中集成，并且给与反馈的过程。团队开发成员经常集成它们的工作，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
CI场景如下：
（1）开发人员向版本控制库提交代码，同时，集成构建计算机上的CI服务器正在轮询检查版本控制库中的变更
（2）在提交发生之后，CI服务器检测到版本控制库中发生了变更，所以CI服务器会从库中取得最新的代码副本，执行构建脚本，该脚本将对软件进行集成
（3）CI服务器向指定的项目成员发成电子邮件，提供构建结果的反馈信息。
（4）CI服务器继续轮询版本控制库中的变更。
CI持续集成周期
一个典型的持续集成周期包括以下几个步骤：
（1）持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新。
（2）如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。
（3）等代码完全更新以后，调用自动化编译脚本，进行代码编译。
（4）运行所有的自动化测试。
（5）进行代码分析。
（6）产生可执行的软件，能够提供给测试人员进行测试。
在CI中您需要一个版本控制库，比如（CVS或者SVN，subversion）来执行CI。版本控制库，大家都知道SVN，可以方便的管理源代码，可以沿着时间轴取得不同同版本的代码。CI服务器在变更提交到版本库后执行的集成构建，他会每个一段时间去检查版本库中的变更，所以我们需要对CI服务器进行配置。CI服务器还需要提供一个方便的显示板来显示构建的结果。但是CI服务器并不是必须的，也可以通过执行构建脚本来执行构建。
从上面我们知道CI的4个基本特征：与版本控制库链接，构建脚本，某种类型的反馈机制，集成源代码变更的过程。这也是CI系统的4个基本功能。一个好的CI系统的关键特征就是速度，这个系统的本质就及时向开发者和项目风险承担者提供反馈信息。
既然CI这么好，但还是有些团队并没有选择使用，其实这是一个综合考虑的结果。使用CI会增加一些成本的，比如增加了维护CI系统的开销，变化太多尤其是对于老项目需要改变很多才能实现CI。失败的构建太多，如果在提交代码之前没有私有构建一次，就会造成在使用ci的时候变更变得频繁。存在额外的硬件和软件成本，使用ci就需要一台独立的集成服务器。
一些需要考虑到的问题
测试能达到多少代码覆盖率？
执行构建需要多长的时间？
平均的代码复杂度如何？有多少代码重复？
在版本控制系统中对构建版本打上标签了吗？
已部署的软件存放在哪里?
是否使用测试覆盖率工具？
如何做好code review？
持续集成工具：jenkins、CruiseControl、Hudson、gauntlet
构建工具：Maven、Ant、groovy
CDBI：持续数据库集成，即每次项目的版本控制库中发生变更时，重建数据库和测试数据。
Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。Jenkins 还提供了非常丰富的插件支持，这使得 Jenkins 变得越来越强大。我们可以方便的安装各种第三方插件，从而方便快捷的集成第三方的应用。
静态代码分析工具，通过扫描Java源代码，发现隐藏在其中的各种问题，包括重复代码，日志记录不规范，异常处理不规范，未使用引入的包，支持ant集成。
这里有关于PMD的一些介绍：
Checkstyle
提供了一个帮助JAVA开发人员遵守某些编码规范的工具。它能够自动化代码规范检查过程。相比于PMD会更加侧重于编码标准（语法）方面的检查，而PMD是侧重于语义bug。
基于Jenkins快速搭建CI环境
首先要知道一个持续集成环境需要包括三个方面要素：代码存储库、构建过程和持续集成服务器。
代码存储库一般使用SVN，
1、开始新建一个 Jenkins 项目， 由于我们需要连接 SVN 的代码存储器， 我们选择 Build a free-style software project。
2、然后配置这个 JenkinsTest 项目了，根据实际的 SVN 服务器服务器信息配置 Source Code Management，这能让 Jenkins 知道如何从哪里获取最新的代码。
3、根据开发需要，隔一段时间需要重新构建一次。选择 Build periodically，在 Schedule 中填写 0 * * * *对应的构建时间。
4、添加 build 的步骤了。Jenkins 提供了四个选项供我们选择，可以根据需要执行或调用外部命令和脚本，例如ant、shell、maven等等。这些脚本都是根据需要自己配置的。
5、可以在 Jenkins 中观察构建的进度和最终的状态&&成功或者失败。太阳代表之前的构建没有任何失败，蓝色的小球代表构建成功。也可以在JenkinsTest 查看单次构建的 Console 的输出结果。从中能看到构建的第一步是从 SVN 服务器上 check out 代码，然后在build。
具体的可以参考：
后话：其实这就是我在公司实习时所谓的CBD，他们没有使用集成工具，而是直接在服务器上执行CBD脚本，check代码，build构建，deploy部署。
阅读(...) 评论()为什么要做持续集成 - yubolin - 博客园
持续集成在目前大多数的公司里都会有这样或者那样的使用。有的会选择一些Open Source的工具，如CruiseControl，Hudson，LuntBuild等等等等，有的会购买有更好服务，更强功能的商业产品，如TeamCity，QuickBuild等等，而有的会选择自己实现，如Cron+Ant/Maven/Make等等。那么使用下来效果如何呢？真得达到了预期的效果吗？我想来恐怕未必吧，否则也就不会有这么多的讨论了。[@more@]
持续集成与敏捷编程
在敏捷领域中，测试驱动和持续集成被称为敏捷编程的两大基石，于是乎，很多人的概念里就是持续集成是为了实现敏捷编程的。这是一个错误的认识。实际上，早于敏捷编程概念的提出，持续集成作为一个best practice就已经被很多公司采用了，只不过作为一个概念，则是由Martin大叔为了推进敏捷所倡导并由此风靡起来。持续集成本身只是一种practice，并不被什么开发模型所限制，在任何一种开发模型中都可以采用，也可以运行得非常理想。
持续集成还是阶段集成
有很多人说，我不做持续集成，照样工作的很好。因为我们一个（小）阶段出一个版本，照样控制得非常好。我得恭喜你，首先持续集成也好，阶段集成也罢，你做了，做了就好，比没有做要好很多，也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。那么究竟那种方式更加理想，更加符合项目的开发和管理呢？其实这个问题Steve McConnell在他那本获得Jolt大奖的书《Code Complete》(代码大全）里有过回答了。他说：对于一个微型程序来说，阶段式的集成或许是最佳方法。何谓微型程序，他说就是那种两三个类的程序，而你又很走运的话，那么阶段式集成就可以是你的最佳方法了。当然，这位老兄是个老美，我们也都知道老外嘛，都比较笨一点，所以呢，他说微型程序，对于我们拥有5000年文明的中国人说，可以再扩大点吧，对于一个小型项目，就是那种二三十个类的项目，也许使用阶段集成也不会出啥子问题吧。不过，你要真的是懒到连个阶段集成都不愿意做的话，那么你至少求求上帝保佑你的项目一切顺利。
为什么要做持续集成
很多人肯定非常不苟同我的看法，他们认为即使没有做持续集成，甚至没有做阶段集成，但是项目一样按时的完成，甚至提前完成，而且照样完成的非常理想，老板满意，客户满意。而做持续集成，无非就是动不动收到一封邮件，说这个build成功了，那个build失败了，不过就是一持续编译罢了，我自己打个命令编译一下，不就知道了吗？要做个daily build，我还要去set up，还要花力气去配置，效果也不见得好到什么地方去。对于这样一些问题，我想首先我们还得搞清楚，究竟为什么我们要去做持续集成，持续集成究竟可以给我们带来什么好处。同样在《Code Complete》里提到了，对于持续集成（在书中，Steve McConnell使用Incremental Integration的术语）有以下几点好处：易于定位错误。也就是当你的持续集成失败了，说明你新加的代码或者修改的代码引起了错误，这样你很容易的就可以知道到底是谁犯了错误，可以找谁来讨论。及早在项目里取得系统级的成果。因为代码已经被集成起来了，所以即使整个系统还不是那么可用，但至少你和你的团队都已经可以看到它已经在那了。改善对进度的控制。这点非常明显，如果每天都在集成，当然每天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你是程序员，你不用在汇报任务的时候说我完成了多少百分比而烦恼，而如果你是项目经理的话，那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。改善客户关系。理由同上。更加充分地测试系统中的各个单元。这也是我们常讲的Daily Build与Smoke Test相结合带来的绝大好处。能在更短的时间里建造整个系统。这点恐怕要你实施以后才能得出结论。就我们而言，持续集成并没有为每个项目都缩短时间，但却比没有实施时，项目更加可控，也更加有保证。随着时间的推移，持续集成带来的更多好处，也逐渐被认识到了，比如说：有助于项目的开发数据的收集。比如说，项目代码量的变化，经常出错的Tests，经常出错的source code，等等。与其它工具结合的持续代码质量改进。如与CheckStyle, PMD, FindBugs, Fxcop等等等等的结合。与测试工具或者框架结合的持续测试。如与xUnit，SilkTest, LoadRunner等等的结合。便于Code Review。在每个build里，我们都可以知道与前一个build之间有什么改动，然后针对这些改动，我们就可以实施Code Review了。便于开发流程的管理。比如说，要把一个开发的build提交给测试组作测试，测完满意了，再提交到发布组去发布。
怎么做持续集成
持续集成有很多很多的好处。可是持续集成要做好的话，本身就有很多的讲究。从持续集成工具的选择到持续集成具体实施，每一点都可能影响到你使用持续集成的效果。持续集成不是持续编译，也不是仅仅用来发发邮件的工具而已。工欲善其事，必先利其器。首先选择一个好的工具很重要，在我另一篇帖子《持续集成工具的选择》中，我已提到过了，这里不再多说。用下来，我觉得QuickBuild真得很不错。工具选好了，具体怎么做呢？这个没有什么标准可以遵循，每个项目都是不一样的，我谈谈我们这里的具体过程吧。首先，我们对编码有一些规范需要遵从，所以我们制定了一系列的FindBugs和PMD的规则用于检查代码。其次，我们使用Cobertura作为我们的代码覆盖（code coverage）工具。再次，我们使用JUnit作为我们的unit test工具基于上述几点，我们编写了我们的Ant脚本，这个脚本有一系列的task，基本上就是:compile, source code analytics, unit test, generate reports, generate javadoc, package artifacts这个，也是Java领域中经常使用的一个完整的过程。有了这样一个脚本以后，我们开始配置我们的项目到QuickBuild中去，在QuickBuild中，我们配置一个configuration，然后设定我们的SCM repository，对应于我们的ant task，我们配置了一系列的step，用于完成整个过程。由于我们的测试需要跨平台，所以对应与同一个unit test的task，我们使用QuickBuild的分布式的step功能，使之在不同平台上可以进行测试，这一点也是使用CI Server的一个好处吧。对应于这个configuration，我们配置了四个子configuration，分布是Development Configuration, QA Configuration，Integration Configuration和Release Configuration。这几个configuration分别对应于我们开发过程的四个阶段，我们的每日构建都是在Development configuration上的，所以我们配置为每日一次，而对于其它三个则不做自动的构建。因为我们是通过Promote来做的。对于Development Configuration，我们没有对SCM自动打Label，而对于其它的，我们则对每一个Build自动对SCM进行打Label。有了这些以后，开发工作开始了，我们每天的代码在下班前都提交到subversion里去，第二天，Development Configuration就自动的编译完成了，并且发送通知给我们。我们通常会会开一个Morning Meeting，首先我们会到在QuickBuild的页面上，看到昨天有哪些个改动，测试的状况，比如说哪些测试修正了，哪些测试还没有被修正，哪些source code没有通过代码检查。然后我们会点到具体的报告中去分析，这些报告都可以很容易的打开source code，我们可以直接在上面对各个改动做code review。通常这个工程耗时约30分钟结束。经过这样开发之后一段时间，我们的功能很多已经就绪，就可以提交给QA作test了，由于当日的构建可能失败，或者不是我们特别想给QA的，那么我们会选择之前几日的一个好的build做Promote，这个promote就会自动触发QA Configuration去做build，QA Configuration的build做完以后，就会发送一个邮件通知QA Lead，这封邮件里QuickBuild会把所有与上一个QA build的changes都列出来，这样他就知道我们这个版本里增加了什么功能，修正了什么bug。再如此经过几个迭代后，我们开发组和QA组一致认为功能基本实现了，bug也不多了，于是就由QA的Lead做一个Promote，触发Integration Configuration不build一个大版本交给客户，做VOC (Voice of Customer)，听却客户的意见，如果客户没有什么易见的话，那么就会在Integration Configuration上做一个Promote到Release Configuration上去。通过这样做，我们基本上可以很容易的知道每一个版本之间有什么变化，甚至我们可以很容易的重新build出任何一个时间点上的版本。而且，我们基本上无需操心什么时候给SCM打什么样的Label，因为对于我们而言，我们需要看到的只是每一个版本的build。而如果用subversion来管理的话，也许你也可以通过命令来列出在SCM中各个版本的变化，但是如果有一天，你头昏忘记打label的话，或者打错label的话，也许要找到这个问题就不是那么容易了。又也许，你可以通过一系列的命令来完成这里提到的所有功能，但是我觉得如果计算机可以完成的话，还是让计算机去做吧。