持续集成相关方案
持续集成相关方案
简介
持续集成是一种软件开发实践，团队成员频繁将他们的工作成果集成在一起（通常每人每天至少提交一次，这样每天就会有多次集成）；每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便能尽早发现集成问题。
在早期，持续集成的过程主要是如下图所示：
主要通过自动化+频繁构建的方式，达到快速验证，快速反馈的目的。
实施方案
持续集成实践思路
- 构建脚本化，搭建持续集成框架。
- 向构建中添加已有的自动化验证集合。
- 选择利于持续集成的分支策略。
- 建立六步提交法。
- 持续优化，工程师改变习惯，并提升技能。
持续集成常见框架
常见的持续集成框架有：
- Jenkins
- GitLab
持续集成常见框架通常主要需要包含整个持续集成实施流程的前、中、后三方面的操作。
基本上所有的持续集成流程，都需要进行以上的配置操作。只是由于团队需求的不同，在配置细节中有所不同。
自动化验证集合
- 向构建中添加自动化测试用例。
- 向构建中加入代码规范扫描。
分支策略
常见的分支策略有：
- 单主干
- GitHub Flow
- Git Flow
- 自定义 Flow
持续集成 6 步提交法
- 主干开发，频繁提交代码。
- 每次提交都是完整有意义的工作。
- 提交构建阶段在 10 分钟之内完成。
- 提交构建失败后，立即修复；且其他人不得在修复之前提交代码。
- 应该在 10 分钟内修复失败，否则回滚引起失败的代码。
- 自动化构建成功后，团队对软件质量比较有信心。
持续优化
优化的内容包括但不限于以下几项：
- 编译打包时间。
- 代码分支策略。
- 自动化测试用例的分层分级。
- 测试验证环境的准备。
- 优化编码规范扫描。
- 生成数据报告。
持续集成准备工作
- 合理的版本控制。
- 自动化构建，而不是手动。
- 技术团队需要达成团队共识。
持续集成前提条件
- 研发团队频繁提交代码：简单问题比复杂问题容易解决，所以越是频繁提交的代码，因为开发量的关系，所以暴漏出来的问题越容易被解决。
- 创建全面的自动化测试套件：如果没有自动化测试，那么即使频繁的集成，也每次都需要手动的发现问题，远比自动化测试要效率低下。
- 保持较短的构建和测试过程：提交前的预编译和测试过程，以及持续集成服务器上的编译和测试过程应该都能在几分钟内结束，因为如果花费的时间越长，大家就越容易丧失耐心。