广义的持续集成：软件开发团队在上述活动的约束下所采用的开发流程。

　　1) 狭义的持续集成

　　一般来说，狭义的持续集成包括如下几个方面：持续检查、持续编译(链接)、持续验证、持续部署、持续基础设施、持续报告等6个方面。

　　持续检查

　　持续检查的目的是保证代码风格一致，主要关注于代码的静态质量和内部质量，比如变量命名方式、大括号位置等等。大部分的现代集成开发环境(IDE) 都具备实时检查代码质量的功能。为了保证主线上的代码质量能够达到一致的标准，应当在持续集成脚本中加入静态检查阶段。比如，Java的PMD、 FindBugs等等。

　　持续编译

　　持续编译是一个很朴素的想法，是保证主线上的代码始终处于可编译的状态。但是这对于很多大中型团队来说却并非想当然的简单。这是因为很多团队并未 采用集体代码所有权策略，导致存在依赖的团队的代码无法编译。针对这样的问题，一方面我们建议采用集体代码所有权;另一方面，对于确实因为安全原因需要隔 离的代码应该边界、明确接口，很少存在大部分代码需要对大部分人保密的情况。

　　持续检查和持续编译是持续集成中基本的验证手段。

　　持续验证

　　持续验证的目的是检查主线上的代码是否能够实现所要求的功能，或者已有的功能是否被破坏。在大部分的构建中，验证部分是耗时长、成本高的部分， 但同时也是收益大的部分。在这个阶段，我们看到的主要问题是验证不充分和验证时间过长。针对这样的问题，我们通常采用分层分级的持续集成策略。后面有详 细的描述。

　　持续部署

　　对于大型软件应用来说，部署往往是一个费时费力又容易出错的步骤，因为这里面涉及到数据迁移、版本兼容等各种棘手的问题。持续部署的思想是将这些工作标准化自动化，使其能够可靠地、自动地、快速地运行。持续部署是当前DevOps运动中的热门话题之一。

　　持续基础设施集成

　　现代大型软件开发，尤其是互联网应用开发中经常依赖于一些常见的基础设施——比如Spring、Tomcat、Database等等。这些基础设施发生变化的时候，我们应当及时地触发持续集成，以确保我们的系统是能够与新的基础设施一起工作的。

　　持续报告

　　报告是将持续集成的状态以适当的形式展现给干系人的基本手段。报告是持续集成的晴雨表，所以它必须直观、易懂，而且对关注点不同的角色展现不同的内 容和粒度。比如，开发人员可能更关心错误的日志;项目经理可能更关心测试覆盖率;产品经理可能更关心持续集成通过率的趋势等等。

　　2) 广义的持续集成及持续集成策略

　　当要把持续集成实践应用到团队的时候，有很多额外的技术或者非技术因素需要考虑。

　　组织结构

　　持续集成是一个重要的沟通工具，而开发过程中两个需要紧密沟通的角色是开发和测试。在我们常见的组织结构中开发和测试往往隶属于不同的部门，甚 至这些部门隶属于不同的高级经理。这往往会给持续集成的推广带来很大的阻力。这是因为持续集成从环境搭建到运行维护都需要两种角色的通力合作。我们的经验 是这类涉及到人力资源的事情除非某一级“共同的大老板”出面，否则是很难协调的。“借调”这样的方式往往不能保证效果。

　　流程

　　放到团队的角度看待流程应当更加关注于各个成员之间的配合。每个开发人员提交代码之前应当确保是经过本地构建的;开发人员在提交之前应该确认主线上的代码是通过了持续集成的;测试人员测试的版本应该是通过了某次持续集成的，并且有相应的具体版本信息。

　　为了保障流程的顺利执行，我们还经常采用持续集成看板、提交令牌等辅助手段。

　　环境

　　环境是指持续集成运行时所依赖的软件和硬件的集合。我们经常遇到的一个问题是，软件在一台机器上能够通过持续集成的验证，而在另一台机器上则不能通 过。这通常是因为我们对持续集成环境的定义不明确造成的。所以在搭建持续集成和在组织内推广持续集成的时候，我们需要特别注意持续集成环境的标准化，明确 指出持续集成运行时依赖哪些第三方库，机器配置如何，端口和网络状况如何等等。

　　我们经常采用将持续集成环境加入配置管理的方式来解决环境标准化的问题。