持续集成（Continuous Integration），

持续集成（Continuous Integration）

•持续集成（Continuous Integration），缩写为CI

p是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每个人每天至少集成一次——这导致每天会集成多次。每次集成是通过自动化的构建（包括测试）进行的，目的是尽快地检查集成错误。许多团队发现这样做能够减少大量的集成问题，让团队能够更快的开发一致的软件。

p自动化的构建：获取版本、编译、单元测试、静态检查、集成测试、系统测试、软件部署、信息反馈等全部自动化。

持续集成是没有任何争议的业界优秀实践

版本控制库、CI(持续集成)服务器、构建脚本、反馈机制

开发人员日常工作步骤：

①开发人员基于最新版本开发1个新特性

②从配置库上将更新过的文件同步到本地，确保本地代码和库文件是最新的

③在本地完成编译、单元测试、代码静态检查

④准备提交代码前再次从配置库上将更新过的文件同步到本地

⑤再次在本地完成编译、单元测试、代码静态检查

⑥成功后向配置库提交代码，自动触发CI集成服务器的一次构建，构建失败后要立即修复直到构建成功

⑦推荐采用令牌方式提交代码

本地构建是开发人员自我质量保证、持续集成质量和版本质量的基础

•微软

p持续集成人员占开发人员的1%，如微软2000人的windows部门，有20人专职做持续集成

pcheck in是头等大事，认为对check in都不认真，那么就没什么事能认真作了。如果check in的代码Build（持续集成）不通过，24小时任何时间通知，必须回公司修正；2次Build不通过会导致责任人在项目组压力非常大，甚至呆不下去。

•Ericsson

p爱立信CTO HAKAN认为爱立信产品交付周期缩短50%，效率不断提升的三个法宝是Daily build（持续集成），Streamline以及One track。

pE公司版本构建3次不通过开发经理将被转岗！

•业界持续集成招聘岗位是软件开发岗位的0.7%

p业界招聘信息看，持续集成岗位的发展速度是软件开发岗位的5倍，招聘岗位是软件开发的0.7%。

•开发效率提升30%

•开发成本节约30％

•错误减少30%

•构建速度提升100%

•配置效率提升40%

•发布频率提升40%

•大型项目的效率提升更大

全球 81.7% 的软件项目采用持续集成

•每天生成可部署的软件，避免产品最终集成时爆发大量问题

p缺陷的检测和修复变得更快

p软件的健康程度可以度量

•团队成员每天都看到自己的可工作的软件成果，增强自信心

•持续集成可以真实的反映产品的开发进度

p可以工作的软件是衡量进度的唯一标准。

p在传统的集成模式下，“最后10%的工作仍需要90%的时间完成”。

p实施持续集成的团队，进度通过特性的完成率来表示，90%的完成率意味着90%的特性开发测试完毕。

•持续集成是产品开发的“心跳”，是产品质量的晴雨表

p开发人员每天的工作都立刻合入版本，构建结果快速反馈给项目经理，项目过程质量一目了然，管理者可以度量真实的进度和质量，确定风险，并积极地进行风险控制。

•增强开发人员自信心

p每次代码修改，团队成员都知道自己的软件遵守编码标准和设计标准，通过测试验证，往前迈进的每一步都非常坚实。

p任务越小，工作越轻松。

持续集成!=持续编译

持续集成!=工具+技术

持续集成!只是开发人员的事情

•任何一点集成方面的努力都是值得肯定的, 哪怕即使只是持续编译，只要保证每天都能够编译通过，也已经具有很大的价值了。

•持续集成关键是：持续测试。即持续集成在很大程度上依赖测试策略和自动化程度。

•持续集成的内涵更多是软件开发理念，绝非只是工具和技术

p持续集成的技术和工具能做的就是自动提供快速反馈

p团队收到反馈之后的行为, 才是降低风险, 提高质量的关键

p持续集成更多的是一种开发文化：工作完成的唯一标准是构建成功

•持续集成更多的是管理（需要管理者下决心），例如制定产品级别的集成策略，包括：

p专用的持续集成硬件环境

p导致主干版本构建失败的行为要严惩

p修复失败的构建是最高优先级的事情

p经常（每天多次）提交代码，提交代码前执行足够多的测试保证质量

p编写自动化的测试用例（UT、IT、ST）

p每次构建必须通过所有测试和审查

•解决版本构建失败的问题是团队最高优先级任务

p最近提交代码的开发者必须参与修复失败的构建

p短期内不能修复的构建代码必须回滚

•开发人员应每天提交至少一次代码

p每天至少向版本控制库提交一次代码。频繁的提交将促使开发人员把工作分解成更小的粒度，既降低工作难度，又有利于监控项目的进展。

•自己提交的代码不能导致其他成员的代码构建失败

p不要提交无法编译或不能通过测试的代码

p开发人员提交代码前必须做本地构建，确保合入代码正确

•开发人员不仅开发代码，更要编写自动化测试用例

p开发人员不仅开发代码，同时要编写自动化的UT、IT的测试用例来验证软件

p开发人员要持续维护和更新自动化测试用例

•开发人员须先在本地构建成功，才可提交代码到配置库

p代码提交到版本控制前；所有代码都必须遵守通用的编码和设计标准，包括编译、PCLINT检查，编程规范检查，常见错误检查，复杂度检查，重复代码检查、UT测试100%通过等。

•始终保证主干版本的构建成功

p保持所有人工作在主干版本上，并且始终保持其能构建成功

p永远不要让主干版本长期处于build不通过的状态

•不要在下班的时候留下失败的构建

•不要在失败的构建上更新、提交代码

•开发、测试及设计共同负责（参与测试场景讨论、测试策略制定、测试结果分析）

•功能测试用例能够及时纳入持续集成环境

p自动化测试设计和实现，与产品代码开发并行

p自动化测试用例在本地调试通过后及时纳入持续集成环境，以便尽早的执行用例发现问题

•持续集成环境中测试失败导致构建失败

p构建成功标准包括自动化测试用例100%通过

p导致构建失败的用例开发和测试要共同关注并及时修复

•管理者重要职责是审视持续集成的结果，出现问题促使尽快解决

p从关注计划、文档到关注持续集成结果的转变，持续集成反映了产品真实的进度和质量。

•保证持续集成人力投入，产品持续集成有专人负责，其职责：

p负责制定产品分级分层分布式的产品持续集成策略

p负责持续集成环境的搭建和维护

p负责维护产品的模块依赖关系（如Makerfile、测试执行的顺序）

p提供在各种不同环境下（如操作系统、硬件配置、软件配置）的工具配置和使用

p及时定位和解决持续集成环境存在的问题

•负责产品持续集成的专人应当是资深员工而不是没有经验的员工

p持续集成需要对产品架构、模块依赖关系、开发活动顺序、环境部署、配置库等都非常熟悉的人才可以制定出正确的产品持续集成策略。

p持续集成是系统工程，涉及设计、开发、测试、工具、技术等之间协同，需要对产品有系统视野的人。

n实践1：单一的代码源，所有软件资产集中管理；

n实践2：经常提交代码，每天至少提交一次代码；

n实践3：不要提交无法构建的代码，提交代码之前先执行本地构建；

n实践4：构建过程完全自动化；

n实践5：每次变更都要触发一次集成构建，在一台独立的构建机器上；

n实践6：立即修复无法通过的构建；

n实践7：使构建足够快，必要的话，采用分级构建策略；

n实践8：将软件部署到接近真实的环境上进行测试；

n实践9：任何人可随时取到最新的可执行程序；

n实践10：所有人都知道最新的构建状态；