持续集成（Continuous Integration），

持续集成（ Continuous Integration ）

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

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

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

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

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

开发人员日常工作步骤：

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

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

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

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

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

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

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

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

• 微软

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

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

• Ericsson

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

p E 公司版本构建 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 ：所有人都知道最新的构建状态；

持续集成（Continuous Integration），

更多文章、技术交流、商务合作、联系博主

微信扫码或搜索：z360901061

微信扫一扫加我为好友

QQ号联系： 360901061

您的支持是博主写作最大的动力，如果您喜欢我的文章，感觉我的文章对您有帮助，请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧，狠狠点击下面给点支持吧，站长非常感激您！手机微信长按不能支付解决办法：请将微信支付二维码保存到相册，切换到微信，然后点击微信右上角扫一扫功能，选择支付二维码完成支付。

【本文对您有帮助就好】元

2元

5元

10元

20元

自定义