开发过程中持续集成分析

持续集成是一种软件开发实践，团队成员频繁将他们的工作成果集成在一起（通常每人每天至少提交一次，这样每天就会有多次集成）；每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便尽早发现集成问题

一次集成过程的流程

开发人员将代码提交到代码仓库
持续集成服务器按一定的时间间隔对代码仓库进行轮询，扫描有变更的代码
持续集成服务器自动将最新代码检出到已准备好的专用服务器上
在专用服务器上运行由持续集成服务器指定的构建脚本或命令，对最新代码进行检查（如代码动静态扫描、编译打包、运行单元测试、部署并运行功能测试等）
运行结束后，将验证结果（成功或失败）反馈给开发团队

“六部提交法”工作步骤

检出最近成功的代码。工程师开始工作时，就要将最近一次构建验证成功的代码版本从团队的开发主干上检车到自己的开发工作区中
修改代码。在个人工作区中对代码进行修改（包括实现产品新特性的代码和编写对应的自动化测试用例）
第一次个人构建。当开发工作完成并准备提交时，首先执行一个自动化验证集，对自己工作区的新代码执行第一次个人构建（也被称为本地构建），用于验证自己修改的代码质量是否达标
第二次个人构建。与主干上的代码进行同步，当有代码冲突时，则需要对冲突代码进行合并（merge），然后再次执行一次质量验证，确保自己的代码与他们的代码都没有问题
提交代码到团队主干。当第二次构建成功并验证后，提交代码到团队开发主干上
提交构建。持续集成服务器发现这次代码变更，立即开始执行提交构建，运行自动化质量验证。如果构建失败，则应该立即着手修复，并马上通知团队成员，禁止其再向团队开发主干提交代码，并且不要检出这个版本

速度与质量的权衡

如何解决自动化测试过长的问题？

分级构建

将自动化验证分成两部分，包含提交构建和次级构建

将运行速度快的、反馈质量高的测试用例，放入提交构建中

将运行较慢或者不经常失败的测试用例放在次级构建环节，作为次级构建验证的内容

多人同时提交的构建
通过云平台的基础设施进行构建

实施持续集成实践

快速建立持续集成实践的6个步骤

构建脚本自动化，搭建持续集成框架

选择一款持续集成工具（例如Jenkins），并完成安装部署。也可以选择使用持续集成云服务

在该集成工具上建立构建任务，并能从你的代码仓库拉取代码

写一个脚本文件，可以自动完成软件项目的编译、构建和打包工作

修改该集成工具上创建的构建任务，使其可以调用写好的脚本文件

向仓库提交一次代码，验证该持续集成工具可以发现更新的代码提交，并拉取正确的代码版本，运行指定的构建脚本

向构建中添加已有的自动化验证集合

向构建中添加自动化测试用例

向构建中添加代码规范扫描

选择利于持续集成的分支策略
建立六步提交法

持续优化

编译打包时间

代码分支策略

自动化测试用例的分层分级

测试验证环境的准备

优化编码规范扫描

生成数据报告。让团队成员都能方便的掌握当前的代码质量状态

工程师改变习惯，并提升技能

持续集成是一个积极的团队协作实践，要求工程师主动提前集成，而不是推迟集成。这与“推迟风险”的心理相违背；需要工程师改变工作习惯，将大块任务尽可能拆分成细粒度的工作

频繁运行自动化测试套件依赖于自动化测试用例的稳定性与可靠性。因此需要工程师投入一些时间来学习相关的方法与技巧

分支策略与部署流水线

“主干开发，主干发布”策略

该策略需要对代码主干做持续集成，只需要架设一个持续集成服务，关注主干代码变更即可

“主干开发，分支发布”策略

该策略需要在准备发布时，创建新的发布分支，并为该发布分支创建对应的部署流水线，因为团队成员会在该分支上修改缺陷，提交代码

“分支开发，主干发布”策略

该策略需要为每个开发分支架设一条对应的部署流水线，并且每当有分支箱主干合入代码时，立即触发主干对应的部署流水线。

当分支上的代码提交不再活跃，或者分支直接被删除后，其对应的部署流水线也可以被删除

多组件集成策略

该策略由多个服务或组件构成，并且每个服务有独立的代码仓库，每个仓库由多人贡献代码。
每个独立代码仓库都可能有自己的不同的分支策略。
此时需要为每个独立的代码仓库建立各自的部署流水线。
然后再创建一条集成用的部署流水线，该流水线并不轮询任何代码仓库，而是由上游的多个部署流水线触发。
一旦上游的部署流水线成功完成，这条集成流水线就需要通过上游流水线产生的软件包进行集成构建验证

常见的实施问题

工程师的开发习惯
视而不见的扫描问题
自动化测试用例的缺乏