持续集成的应用

1、 持续集成的应用客户第一 | 阳光沟通 | 团队协作 | 拥抱变化 | 学习成长持续集成目的持续集成流程、作用及原则持续集成工具使用介绍持续集成概念持续集成在飞看流程目录持续集成目的持续集成流程、作用及原则持续集成工具使用介绍持续集成概念持续集成在飞看流程目录持续集成目的及早集成，及早发现问题！提前并频繁地做让你感到痛苦的事!持续集成，达到持续发布目的！持续集成目的持续集成流程持续集成工具使用介绍持续集成概念持续集成在飞看流程持续集成相关概念(一)l自动化(automated)：一个”无须干预”的过程。当一个完全自动化的过程开始后，不需要用户的干预。系统管理员称之为“无人值守”过程。l构建(b

2、uild)：编译、审查、部署及测试软件的一组活动。l持续(continuous)：从技术上讲，持续意味着一旦开始就永不结束。这意味着构建会不断进行，但实际上并非如此。CI中的持续更像是坚持，一个进行不断运行，轮询版本控制库的变更。如果CI服务器发现了变更，就会执行构建脚本。持续集成相关概念(二)l持续集成(Continuous Intergration):”简称CI。一项软件开发实践，其中团队的成员经常集成他们的工作，通常每个人每天至少集成一次”-这导致每天会集成多次。每次集成是通过自动化的构建(包括测试)进行的，目的是尽快地检查集成的错误。许多团队发现这样做能够减少大量的集成问题。让团队能够

3、更快地开发一致辞软件。l持续交付(Continuous Delivery)：通过持续集成部署流水线达到发布条件，经常地可获得可交付的版本。持续集成相关概念(三)l开发环境(Development Environment)：软件编写的环境。这包括IDE，构建脚本，工具，第三方的库，服务器和配置文件等。l审查(Inspection)：出于内部质量要求，对源代码/字节码进行分析。将自动化的审查(包括静态分析和运行时分析)称为“软件审查”。l私有构建(Private Build)：将变更提交至配置库之前，在您的开发环境中执行的本地构建。目的是减少最近的变更破坏集成构建的可能性。持续集成目的持续集成流程

4、、作用及原则持续集成工具使用介绍持续集成概念持续集成在飞看流程持续集成的流程持续集成包括的范围目标：只需要点击一下鼠标，就可以将软件部署到任何目标环境，包括开发环境、测试环境或生产环境。上述各项工作都持续进行、持续反馈各种潜在的问题将被持续地暴露和跟进，进而保证持续发布。持续集成流程持续集成阶段为减少构建时间，快速反馈一般分为提交阶段与验收阶段对应轻量级构建及重量级构建轻量级构建：对软件编译、规范性检查(静态检查)、单元测试等（如有的有冒烟测试）排除所有明显的问题重量级构建:执行更全面的集成构建，包括部署与测试（有的包括动态检查）1. 小组成员check in 代码到源码库中。2. 自动开发服

5、务器不断的监测该源控制库3. 新代码不断的被该服务器check out。4. 不断地编译、打包、规范性检查、单元测试、自动安装与部署、自动测试5. 结果发出报告。持续构建流程持续集成实施一般步骤1、自动化1.1 包括但不是非要全部包括：自动编译、自动单元测试、自动规范性检查、自动安装与部署、自动测试，没有严格顺序1.2 自动工具编译打包工具：ant 、mvn、make单元测试：junit cppcheck规范性检查：checkstyle、findbug等2、执行单命令构建通过单命令(可是批处理)可运行自动构建，并出具相应报告持续集成实施一般步骤3、使用持续集成工具将流程形成反馈3.1 实现定时

6、或轮询配置库，获取软件源码，进行自动编译打包、单元测试、规范性检查生成报告。3.2 定时或轮询已生成的二进制包，自动安装与部署、自动接口测试、功能性测试、性能测试等生成报告。持续集成的机制根据实际情况定。3.3 反馈方式多种：邮件、SMS等持续集成带来的好处作用描述及早发现缺陷CI每次变更时(或每天多次)就执行测试与审查，能尽早发现缺陷减少重复过程CI减少重复过程，包括编译、单元测试、审查、部署与测试减少假定 CI通过在一个干净的环境中不断使用相的过程和脚本重复构建，减少第三方环境的依耐每次提交都可能产生一个可发布的软件 因CI及时经常地部署测试，软件的质量情况可以测量与追踪，可得到可发布的版

7、本增强项目的可见性因CI可提供质量情况，作为有效的决策，同时也可关注到其趋势建立起更强大的产品信心因CI，让项目团队清楚软件通过测试验证其行为,也清楚代码的修改造成的影响持续集成的前提条件1、版本控制全面的地配置管理，与项目相关的所有内容必须提交至版本库中。2、自动化如果没有一系列全面的自动化测试，那么构建成功只意味着能够编译3、团队共识持续集成不是一种工具，是一种实践，需要投入并遵守一些规则，才能提高质量持续集成的实践1. 经常提交代码2. 构建失败后不要提交新代码3. 不要提交无法构建的代码4. 立即修复无法集成的构建5. 回家前，构建必须处于成功状态6. 时刻准备回滚到前一版本7. 在回

8、滚前规定一个修复时间8. 不要将失败的测试注释掉9. 为自己导致的问题负责10.测试驱动开发必不可少实践持续集成的实践1. 极限编程开发实践2. 违备架构原则，就让构建失败3. 若测试运行变慢，也让构建失败4. 若编译警告或代码风格问题，就让测试失败推荐实践持续集成原则一u为软件的发布创建一个可重复且可靠的过程几乎将所有的事情自动化将构建、部署、测试和发布软件所需的东西全部纳入到版本控制管理之中持续集成的原则二u将几乎所有的事情自动化自动化是部署流水线的前提条件。当然你不需要把所有的东西一次性地全部自动化，你应该看一下在构建、部署、测试和发布过程中，哪个环节是瓶颈，随着时间的推移，最终你可以，

9、也应该将所有的环节自动化。持续集成的原则三u把所有的东西都纳入版本控制将构建、部署、测试和发布的整个过程中所需要的东西全部保存在某种形式的版本存储库中，包括需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、数据库创建、升级、回滚和初始化脚本、应用程度所领带的软件集合的配置脚本、库文件、工具链以及技术文档等。与每次构建结果的相关的版本都可以识别。持续集成的原则四u提前并频繁地做让你感到痛苦的事这是最通用也是最有启发性的原则持续集成的原则五u内建质量整个团队必须执行铁一般的纪律：一旦发现缺陷，就要马上着手修复两个推论：p 测试不是一个阶段，当然也不应该开发结束之后才进行p 测试也不纯粹或

10、主要是测试人员的领域。交付团队的每个人都应该对应用程序的质量负责持续集成的原则六u Done意味着已发布(非1即0)u 交付过程是每个成员的责任u 持续改进持续集成目的持续集成流程、作用及原则持续集成工具使用介绍持续集成概念持续集成在飞看流程持续集成的成熟度 该评估方法借鉴了ThoughtWorks敏捷成熟度模型，进行简化。持续集成成熟度( e-Business )-1级手动的0级可重复的 1级重复执行2级频繁的 3级对内防御的 3+级对外防御的 持续集成成熟度评估( e-Business )-1级 ：主要依赖于手动的方式集成软件。每次集成的方式可能不一样。0 级 ：主要依赖于手动的方式构建软

11、件，但是每次构建的方式都是相同的或者相似的。通常有相关的文档的指导。 1级：构建是自动的，但是执行的不够频繁。构建的触发是随机的或者频率是非常低的（低于每天一次）。构建的速度通常非常慢，比如一次构建超过半个小时。 持续集成成熟度评估( e-Business )2级：构建是自动的，而且构建的速度较快。构建的触发条件是明确的，通常每次代码提交都会触发构建。团队中的每个人都会触发构建，并且了解构建的状态 。 3级：构建是自动的。由测试和检查来保证团队内部的开发质量。持续集成的修复具有最高的优先级。团队对持续集成的结果有信心。 3+级：团队能够根据自己的需要，协调其他团队的持续集成，当依赖的其他团队的

12、代码和组件或者第三方库和基础设施发生改变时自动进行构建。团队对于外部依赖的可靠性有信心。 持续集成成熟度( e-Business )-1级手动的0级可重复的 1级重复执行2级频繁的 3级对内防御的 3+级对外防御的 我们在哪一级？测试成熟度( e-Business )-1级独立的0级审查的1级共享的2级集成的 3级测试驱动的3+级全面集成的测试成熟度( e-Business )-1级 ：测试由专门的测试人员负责。仅在软件开发结束后执行。 0 级 ：测试由专门的测试人员负责。有部分测试是在软件开发过程中执行。但大部分测试在软件开发结束后执行。 1级：开发人员参与测试。测试并未集成在构建过程中。部

13、分测试在软件开发过程中执行，大部分测试在软件开发结束后执行。 测试成熟度( e-Business )2级：开发人员参与测试。部分测试集成在构建过程中执行。大部分测试在软件开发过程中执行。3级：业务分析人员和开发人员均参与测试。测试在构建过程中自动执行。开发人员实践测试驱动开发3+级：全团队对测试负责。测试驱动整个开发过程。测试与构建完全集成。 测试成熟度( e-Business )-1级独立的0级审查的1级共享的2级集成的 3级测试驱动的3+级全面集成的老兄，我们又在哪里？持续集成三大环境习惯改变，从这里开始开发人员的一天从Daily Build开始 开发人员上班的第一件事儿就是查看Daily

14、 Build的结果，看是否由于自己昨天的代码Check-in，造成Build Broken 查看地址：66:8080/hudson-2.2.065:8080/hudson-2.2.0习惯改变，从这里开始OK，Year!习惯改变，从这里开始开发环境全面升级为昨晚的版本 查看构建结果，若不成功，必须先修复完成，等待下一次构建的成功。连续三次后，有MM送你大头贴的喔习惯改变，从这里开始开发环境全面升级为昨晚的版本 构建成功后，从自动构建环境中获取软件包，开发环境升级昨晚的版本 从指定路径直接下载软件包：网页下载或直接下载6

15、6output65xiehuihudson习惯改变，从这里开始从这里下载习惯改变，从这里开始开发验证昨天的完成情况 打开禅道Bug管理工具，验证自己的BUG，更新禅道BUG状态 打开禅道任务，验证自己昨天的任务，更新任务完成状态习惯改变，从这里开始开始修复今天的BUG及完成今天的禅道任务 查看禅道指定给自己的Bug，解决高优先度的Bug。因为质量重于新功能 打开禅道任务，开始动工完成分给自己的任务接下来，开发人员会从源代码管理工具中Check out代码修改代码（解决Bug或实现新功能）取得源代码管理工具中最新变化，在本机Build和单元测试请开发组同事作Code Revie

16、w写日志，Check in代码在禅道Bug管理工具中修改Bug的状态开发人员以一封Daily Report结束一天的工作代码上传测试人员第一件事做什么？升级软件包，验证BUG 从持续集成环境中下载软件包升级 打开禅道管理工具，查看指定给自己的Bug，,验证已解决的Bug测试人员第一件事做什么？点击这里一看就知道开发的变更记录测试人员第一件事做什么？童鞋们，变更日志写没写清楚，测试一看就知道接下来，测试人员会 根据测试用例检验当天的Build 在禅道Bug管理工具中录入新发现的Bug，等待开发人员解决下班前，测试人员会 发送当天或者一周的Bug报告和测试用例报告测试人员说明 上述测试是开发过程中的测试，正式某个版本转测试走转测流程 上述测试人员包括体验人员飞看的持续集成 1、做了自动编译，还未做自动测试 2、自动编译做了两个层级 部件级 集成级飞看的持续集成6a801S1001appstoreAndroidTVPortalMovieonLine持续集成目的持续集成流程、作用及原则持续