¶ 持续集成规范
¶ 1.概述
持续集成是软件工程领域中的一种最佳实践，即鼓励研发人员频繁的向主干分支提交代码，频率为至少每天一次。每次提交都触发完整的编译构建和自动化测试流程，缩短反馈周期，出现问题第一时间进行修复，从而保证软件代码质量，减少大规模代码合并的冲突和问题，让软件随时处于可发布状态。
¶ 2.术语解释
| 术语名称 | 术语解释 |
|---|---|
| 自动化 automated | 一个“无需干预”的过程。当一个完全自动化的过程开始之后，不需要用户的干预。 |
| 构建 build | 生产、测试、审查和部署软件的一组活动。 |
| 持续 continuous | CI中的持续更像是坚持，一个进程不断运行，轮询版本控制库的变更。如果CI服务器发现了变更，就会执行构建脚本。 |
| 持续集成 Continuous Integration | 一项软件开发实践，其中团队的成员经常集成他们的工作，通常每个人每天至少集成一次，这导致每天会集成多次。每次集成是通过自动化的构建(包括测试)进行的，目的是尽快地检查集成错误。 |
| 开发环境 development environment | 软件编写的环境。这包括IDE、构建脚本、工具、第三方的库、服务器和配置文件等。 |
| 审查 inspection | 出于内部品质要求，对源代码/字节码进行分析。本文中将自动化的审查(静态分析和运行时刻分析)称为”软件审查“。 |
| 集成 integration | 将各部分源代码结合到一起，确定它们时刻能作为一个整体工作。 |
| 集成构建 integration build | 将软件组件(程序和文件)结合成一个软件系统的动作。得到的构建版本对于较大项目来说可以包含多个组件，对于较小的项目来说只是包含低级的、编译过的源文件。本文中“集成构建”特指在独立的集成构建计算机上执行的构建。 |
| 私有/系统构建 private/system build | 将变更提交到版本控制库之前，在您的工作站上执行的本地构建，目的是减少最近的变更破坏集成构建的可能性 |
| 品质 quality | 本文中“品质”是可测量的规格说明，和其他行业一样。这意味着您可以确定具体的品质测量指标，如可维护性、可扩展性、安全性、性能和可读性等。 |
| 发布构建 release build | 准备将软件发布给用户。这可能发生在一次迭代结束时或达到某个里程碑时，必须包括验收测试，可能还包括大量的性能测试和负载测试。 |
| 风险 risk | 问题发生的可能性。已经成为现实的风险就称为“问题”。我们关注发生可能性较大的、较高优先级的风险。 |
| 测试 testing | 验证软件是否按设计工作的一般过程。而且，我们把开发者测试分成几类，如单元测试、组件测试、系统测试等，它们验证对象、包、模块和软件系统是否按设计工作。还有许多其他类型的测试，如功能测试和负载测试、但从CI的角度来说，至少所有由开发者写的单元测试都要在构建时进行(但构建可以分级别，先执行较快的测试，在执行较慢的测试) |
¶ 3.前提条件
在开始持续集成之前，需要先做好以下事情，以让持续集成能够更加有效：
¶ 3.1 频繁提交
- 研发人员至少每天一次的将代码提交到主干上。
¶ 3.2 全面的自动化测试套件
- 单元测试用于单独测试应用程序中某些小单元的行为(比如一个方法、一个函数， 或一小组方法或函数之间的交互)。
- 单元测试应该运行得非常快，即使对于一个大型应用来说，整个单元测试套件也应该在十分钟之内完成。
¶ 3.3 保持较短的构建和测试过程
- 理想情况下，提交前的预编译和测试过程，以及持续集成服务器上的编译和测试过程应该都能在几分钟内结束。我们认为十分钟是一个极限了，最好是在五分钟以内，九十秒内完成是最理想的。
- 测试需要划分阶段，第一个阶段用于编译软件，运行所有类级别的单元测试，并创建用于部署的二进制文件。这个阶段叫做“提交阶段”。
- 第二个阶段应该利用第一个阶段所生成的二进制文件进行验收测试、集成测试。假如你有性能测试的话，也要一并运行。
¶ 3.4 管理开发工作区
- 开发环境的管理目标：
- 当开发人员刚开始新任务时，应该总是从一个已知正确的状态开始。
- 开发人员应该能够运行构建、执行自动化测试，可以在开发机上部署其开发的应用程序。只有在特殊的情况下，才应使用共享环境开发。
- 在本地开发环境上运行应用程序时，应确保所使用的自动化过程与持续集成环境、测试环境、生产环境中一致。
- 达到这一目标，需要做以下事项：
- 第一个先决条件就是细心的配置管理，将源代码、测试数据、数据库脚本、构建脚本和部署脚本放在版本控制库中。当编码开始时，应该以它们“最新的正确版本”作为起点。“最新的正确版本”是指那个在持续集成服务器上最近一次通过所有自动化测试的那个版本。
- 其次是确保第三方依赖的配置管理（开发中所用的库文件和组件）的版本与正在开发的源代码的版本是相互匹配的。对于大部分项目来说，其所依赖的第三方库文件的版本不会经常发生改变，所以最简单的方法就是将这些库文件随你的代码一起提交到版本控制库中。
- 最后就是确保自动化测试(包括冒烟测试)都能够在开发机上运行。让开发人员于每次提交前在自己的开发机上将应用程序运行起来，并在其上跑一遍冒烟测试，可以大大改善应用程序的质量。
¶ 4.系统角色定义
¶ 4.1 运维人员
- 搭建持续集成环境和工具
- 持续集成和部署任务配置，相关脚本编写
- 持续集成环境维护、账号及权限配置
¶ 4.2 开发人员
- 开发软件，代码编写和管理
- 集成、部署开发环境
¶ 4.3 测试人员
- 部署测试环境
- 执行测试任务
¶ 5.代码管理
¶ 5.1 分支管理
¶ master 主分支
对应线上（正式环境）的代码，版本上线由测试人员确认，通知开发人员将对应上线版本合并至master分支并打tag，准备部署或更新至生产环境。
¶ dev-版本号 开发分支
- 基于开发分支进行功能开发、Bug修复等，命名建议：dev-版本号。
- 开发版本部署到开发环境进行集成、测试。
¶ test-版本号 开发测试分支
当开发在开发环境测试完成以后，合并到内部测试分支：test-版本号，将功能移交给内部测试人员进行测试，内部测试人员部署到内部测试环境进行测试。
¶ release-test-版本号 生产测试分支
当内部测试完成后，合并到生产测试分支：release-test-版本号，将分支提交到测试组，由测试组负责部署到生产测试环境进行测试。
¶ 5.2 TAG管理
¶ release-版本号 发布TAG
当测试组完成生产测试全部工作后，对生产测试分支进行tag操作，并根据产品发布计划，基于tag进行生产发布。
¶ 6.自动构建/部署
基于Jenkins工具进行自动构建/部署流程，具体参考以下内容：
¶ 6.1 自动构建/部署的详细流程如下：
- 创建构建/部署任务；
- 依据各产品的开发特点，研发人员定期完成代码提交；
- 研发人员提交测试申请单；
- 测试人员按照产品发布特性，创建Jenkins的执行任务，并自动执行将产品发布的代码布署到指定的应用服务器上，完成应用服务器代码自动更新；
- 测试人员配置好自动化测试用例脚本执行测试，完成自动测试并出测试报告；
- 测试人员按照测试用例执行功能测试并提交测试进度及测试报告；
- 开发人员修复BUG后再次发布产品代码直至所有问题修复完成；
- 重复第4、5、6步
- 测试人员验证BUG并做回归测试完成；
- 研发人员将test分支的代码合并到release分支；
- 执行Jenkins任务,完成代码发布更新；
- 完成手动、自动化测试；
- 测试完成，研发人员与测试人员准备发布更新包到现场。
¶ 6.2 产品持续集成需完成的任务
- 研发人员每天或定期完成代码提交到项目私有分支；
- 研发人员完成代码自测；
- 研发人员定期将代码提交到测试分支；
- 研发人员发送测试申请单；
- 研发人员需配合测试人员，对代码编译问题的排查及环境配置，确保编译打包通过；
- 研发人员每天或测试人员每天检查jenkins项目任务build的情况，若失败将问题汇报给研发人员并修复；
- 测试人员维护相关项目任务的自动化测试脚本，确保测试脚本运行无误；
- 研发人员将test分支代码合并到release分支
- 测试人员测试releaes分支的更新包。