第九章：持续集成

起源与定义
　　定义：
　　　　持续集成是一种软件开发实践，团队成员频繁将他们的工作成果集成在一起（通常每人每天至少提交一次，这样每天就会有多次集成）；每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便能尽早发现集成问题。
　　一次集成过程：
　　　　1.开发人员将代码提交到代码仓库
　　　　2.持续集成服务器按一定的时间间隔（如每隔一分钟）对代码仓库进行轮询，发现有代码变更
　　　　3.持续集成服务器自动将最新代码检出到已准备好的专用服务器上（如果应用规模不大，可以与持续集成服务器是同一台机器）
　　　　4.在专用服务器上运行由持续集成服务器指定的构建脚本或命令，对最新代码进行检查（如代码动静态扫描、编译打包、运行单元测试、部署并运行功能测试等）
　　　　5.运行结束后，将验证结果（成功或者失败）反馈给开发团队
六步提交法
　　具体步骤：
　　　　1.检出最近成功的代码：工程师开始工作时（例如工作日早上刚刚开工认领了一个新的开发任务），就要将最近一次构建验证成功的代码版本从团队的开发主干上检出（check out）到自己的开发工作区中
　　　　2.修改代码：在个人工作区中对代码进行修改（包括实现产品新功能的代码，甚至编写对应功能的自动化测试用例）
　　　　3.第一次个人构建：当开发工作完成并准备提交时，首先执行一个自动化验证集，对自己工作区的新代码执行第一次个人构建（有时也被称为本地构建），用于验证自己修改的代码质量是否达标
　　　　4.第二次个人构建：从“检出代码”到“第一次个人构建完成”这段时间内，很可能在开发主干上有其他成员已提交了新代码，并通过了持续集成的质量验证。此时，需要将这个版本的代码与自己本地修改的代码进行合并（merge），然后再次执行一次质量验证，确保自己的代码与其他人的代码都没有问题
　　　　5.提交代码到团队主干：当第二次个人构建成功后，提交代码到团队开发主干
　　　　6.提交构建：持续集成服务器发现这次代码变更，立即开始执行提交构建，运行自动化质量验证。如果这次构建失败，则应该立即着手修复，并马上通知团队成员，禁止其再向团队开发主干提交代码，并且不要检出这个版本
　　团队开发主干：团队成员共同拥有的一个代码仓库分支，即每个开发人员完成任务后，需要将代码提交到该分支上，与团队其他人的代码合并在一起
　　个人工作区：团队成员自己用于修改代码的本地工作目录
　　个人构建（也叫本地构建或本地验证）：团队成员在提交代码变更到代码仓库之前，对自己的变更集进行质量验证的活动，其目标是确保自己的代码修改符合功能预期，同时也不会破坏原有功能
　　六步提交法的四个关键点：
　　　　1.六步提交法中的3次验证有什么作用
　　　　　　六步提交法中有3次质量验证活动，分别是第3、4和6步
　　　　　　第3步的个人验证目标是验证开发者自己修改过的代码是否正确
　　　　　　第4步的个人验证是确保其他人的代码与自己的代码合并后，两部分的代码质量都没有问题
　　　　　　第6步的提交构建验证是在一个干净且受控环境中执行与第4步个人构建相同的内容，以确保开发人员的本次提交是完整且无质量问题的，没有遗漏
　　　　　　　　假如第4步的个人验证成功，第6步提交构建验证失败，可能有以下原因
　　　　　　　　　　自己这次代码提交并不完整，有一部分代码修改被遗漏啦
　　　　　　　　　　自己的机器环境与整个团队标准化验证环境有差异
　　　　　　　　　　团队其他成员在自己提交前再一次提交了新的代码，但自己没有注意到
　　　　2.个人验证一定要做两次吗
　　　　　　第一次个人验证的目标是验证自己的修改是符合质量预期的
　　　　　　第二次个人验证的目标是验证自己改动的代码和其他人提交的代码合并在一起，也符合质量预期
　　　　　　假如第一次成功，第二次失败，说明从主干上合并回来的代码对自己的修改产生了影响。因此做两次验证比较容易定位问题
　　　　　　可以只进行一次个人验证，应该保留第二次个人验证
　　　　3.如何确保在提交前执行个人构建
　　　　　　一种方式是在提交代码之时，由持续集成平台通过钩子（hook）捕获提交事件，在代码合并到主干之前，强制进行第二次个人验证。
　　　　　　另一种方式就是通过团队口头约定的方式，要求团队成员遵守这一要求
　　　　4.每次构建应该包含哪些质量验证内容
　　　　　　自动化单元测试、代码动静态扫描、代码规范检查、构建验证测试等
　　　　　　构建验证测试：
　　　　　　　　1.构建结束后生成的二进制包是否包含了正确的内容，例如配置文件的完整性
　　　　　　　　2.这个构建结果是否能够正确安装并正常启动运行起来
　　　　　　　　3.启动后最基本的功能是否可以使用，如用户登录等
　　　　　　代码规范检查中，针对有大量遗留代码的代码库，经过规范扫描可能发现数量巨大的已存问题，此时可以采取以下两种措施
　　　　　　　　1.减少规范，关注重点。团队应该在一起讨论，提取最重要的代码规范，早期只关注严重类型的问题，之后再逐步增加代码描述规则
　　　　　　　　2.执行“童子军营地原则”。在保证每次提交代码时，不让问题数量继续增长，假如每次能递减就更好啦

　　同步与异步模式
　　　　同步模式：开发人员必须等待第6步“提交构建”结束并返回结果之后，再决定下一步的行动，即“每个开发人员编程一段时间后就立即进行一次集成，集成时间不应该超过10分钟。等待这次构建结束，并且整组自动化测试运行完成，确认质量达标，无须回退后，再开始下一项工作”
　　　　异步模式：开发人员在完成第5步“代码提交”后，并不需要等待提交构建阶段结束，就可以着手下一项工作任务
　　　　不建议异步模式
　　自查表
　　　　1.主干开发，频繁提交：
　　　　　　主干开发是指参与开发同一软件项目或服务的所有团队成员向该软件项目仓库的主干分支上提交代码，或者其他分支的生命周期不超过3天
　　　　　　频繁提交是指每人每天至少提交一次，最好每工作几小时就进行提交
　　　　2.每次提交应该是一个完整的任务
　　　　　　每次提交的内容应该是有意义的，而不只是为了达到提交频率的要求而随意提交代码
　　　　3.让提交构建在10分钟以内完成
　　　　4.提交构建失败后应立即停止团队成员提交新代码，也不许其他人检出改代码
　　　　5.立即在10分钟内修复已失败的提交构建，否则回滚代码
　　　　6.自动化构建验证通过后，对软件质量有比较大的信心
　　　　　　不建议忽略或者删除自动化测试用例
速度与质量的权衡
　　分级构建：自动化验证分成两部分
　　　　将运行速度较快、比较容易失败的测试用例，放入提交构建中
　　　　将运行较慢、失败可能性较低的测试用例放在次级构建环节
　　　　当提交构建验证成功后，马上触发次级构建的执行，这时开发人员只需提交构建验证成功，即可开展其他任务，不必等待次级构建验证完成返回结果
　　多人同时提交的构建
　　　　如果次级构建运行时间长（30分钟以上），当多人连续提交代码时，很容易出现提交构建均已经运行完成，但前面的次级构建还没有结束，仍旧在运行的情况
　　　　　　资源不受限的情况，可以在每次提交构建成功之后，立即触发相应的次级构建
　　　　　　资源有限或者提高资源有效利用率，次级构建验证可以包含多人提交的内容
　　云平台的威力
　　　　云计算基础设施的发展为持续集成提供了更强大的资源支持和便利性。我们可以将那些比较耗时和耗资源的步骤放入云平台中执行，执行结束后将验证结果通知构建的所有者。
在团队中实施持续集成实践
　　快速建立团队的持续集成实践
　　　　1.构建脚本化，搭建持续集成框架
　　　　　　选择一款持续集成工具，并完成安装部署。比如国内比较流行的Jenkins
　　　　　　在该持续集成工具上建立一个构建任务，可以从你的代码仓库拉取代码
　　　　　　写一个脚本文件，可以自动完成软件项目的编译、构建和打包的工作
　　　　　　修改刚刚在该持续集成工具上创建的构建任务，使其可以调用写好的这个脚本文件
　　　　　　向仓库提交一次代码，验证该持续集成工具可以发现有新代码提交，并拉取正确的代码版本，运行指定的构建脚本
　　　　2.向构建中添加已有的自动化验证集合
　　　　　　向构建中添加自动化测试用例（至少一个自动化测试用例放到这个构建任务）
　　　　　　向构建中加入代码扫描规范
　　　　3.选择利于持续集成的分支策略
　　　　4.建立六步提交法
　　　　5.持续优化
　　　　　　优化的内容包括但不限于以下几项
　　　　　　　　编译打包时间：通过引入各种工具，或者重新组织和优化编译找包脚本，系统模块拆分与组合等
　　　　　　　　代码分支策略：随着持续集成的深入，团队会进一步选择利于持续集成的分支策略
　　　　　　　　自动化测试用例的分层分级：
　　　　　　　　　　分层是指按测试目标分层，如单元测试、集成测试和端到端的测试等。
　　　　　　　　　　分级是指按反馈速度和反馈质量进行分级，在资源不充裕的情况下，将各种测试用例放入不同的级别中（如提交构建任务和次级构建任务），并按线性方案顺序执行
　　　　　　　　测试验证环境的准备
　　　　　　　　优化编码规范扫描
　　　　　　　　生成数据报告
　　　　6.工程师改变习惯，并提升技能
　　分支策略与部署流水线
　　　　“主干开发，主干发布”策略：
　　　　　　只有一个代码仓库，只需架设一个持续集成服务，关注代码主干的代码变更即可
　　　　“主干开发，分支发布”策略：
　　　　　　只有一个代码仓库，每当准备发布时应该创建新的发布分支，并未这个发布分支创建对应的部署流水线
　　　　“分支开发，主干发布”策略：
　　　　　　只有一个代码仓库，团队需要为每个开发分支架设一条对应的部署流水线，并且每当有分支向主干合入代码时，立即触发主干对应的部署流水线。当分支上的代码提交不再活跃，或者分支直接被删除后，其对应的部署流水线也可以被删除
　　　　“多组件集成”策略：
　　　　　　本策略是指软件产品由多个服务或组件构成，并且每个服务（或组件）有独立的代码仓库，每个仓库由多人贡献代码。此时，每个独立代码仓库可能都有自己不同的分支策略
　　　　　　可以根据上面所讲的3种不同策略，为每个独立代码仓库建立各自的部署流水线
　　　　　　然后，再创建一条集成用的部署流水线，该流水线并不轮询任何代码仓库，而是由上游的多个部署流水线触发。
　　　　　　一旦上游的部署流水线成功完成，这条负责集成的流水线就应该对获取上游流水线生产的软件包进行集成构建验证
常见的实施问题
　　工程师的开发习惯
　　　　工程师习惯于长时间不与其他人的代码进行集成，则在刚刚开始使用持续集成实践时，很难达到“持续集成最佳状态”，如小步提交、代码完整、不影响已有功能等
　　视而不见的扫描问题
　　　　团队成员对扫描规则没有达成一致，部分工程师对其中的问题有异议，但这种异议被管理者忽视
　　　　　　团队技术管理问题，代码规范没有统一标准。此时应该由团队技术负责人与团队一起学习代码规范，讨论并制定团队的代码标准，并记录达成一致的检查项，再进行自动化扫描
　　　　扫描出来的问题太多，无从下手修复
　　　　　　通常发生在产品研发进度紧张的时候。此时应该执行“童子军营地法则”，即保证质量指标不再恶化
　　自动化测试用例的缺乏
真正做到持续集成，获得最大的持续集成收益，需要做到以下6点
　　1.主干开发，频率提交代码
　　2.每次提交都是完整有意义的工作
　　3.提交构建阶段在10分钟之内完成
　　4.提交构建失败后，立即修复；且其他人不得在修复之前提交代码
　　5.应该在10分钟之内修复成功，否则回滚引起失败的代码
　　6.自动化构建成功后，团队对软件质量比较有信心