持续交付和devops（3）

specialApe logic 2022-11-05

373

今天和一篇聊一聊持续交付中开发和测试两类人员最密切相关的一个步骤-持续集成。最初起源于20世纪60年代末的一个著名软件项目，它就是Chrysler Comprehensive Compensation System（简称C3 项目）这个项目本身的投资回报率，并不高，但是很多软件开发实践在这个项目中都有所应用。C3 项目于 1993 启动， 1994年用Smalltalk开发，终极目标是在 1999年支持87000雇员的综合人事与工资系统。直到1996年，这个软件系统还无法运行。

有个非常令人头疼的问题，那就是“把项目代码集成在一起，启动并运行起来”。这一集成联调的过程非常痛苦，常常需要两周才能搞定。于是他们决定经常做系统集成工作，集成频率逐渐提高。虽然在刚开始提高集成频率时，团队感觉比较痛苦，但是每次集成所花费的时间显著减少，而且集成过程中发现的问题比之前更容易定位修复。

于是，团队人员有了更加疯狂的想法：“既然提高集成频率可以让问题更早且更容易发现，修复时间更少，那么，为什么不做得更频繁些，在每次提交代码以后就做代码集成呢？”于是，团队的开发人员就写了一系列的shell脚本，其用途是：通过定期访问代码仓库，只要发现有新的代码变化，就将代码自动拉取到事先准备好构建环境的干净机器上（事先在这台机器上已安装好编译所需的工具或库）进行构建。一旦结束，就会将构建结果通过屏幕显示出来。

对于开发者一类的个体来说：持续集成的过程意味着这样的通用性流程：

(1）开发人员将代码提交到代码仓库。

(2）持续集成服务器按一定的时间间隔（如每隔30分钟）对代码仓库进行轮询，发现有代码变更。

(3）持续集成服务器自动将最新代码检出到已准备好的专用服务器上（如果应用规模不大，可以与持续集成服务器是同一台机器）。

(4）在专用服务器上运行由持续集成服务器指定的构建脚本或命令，对最新代码进行检查（进行代码动静态扫描、编译打包、运行单元测试、部署井运行功能测试等）。

(5）运行结束后，将验证结果（成功或者失败）反馈给开发团队。

四个关键点：

1.提交法中的三次校验有什么用？

命令相同，脚本一致，为什么还要执行三次呢？第3步的个人验证目标是验证开发者自己修改过的代码是否正确。第4 步的个人验证是确保其他人的代码与自己的代码合并后，两部分的代码质都没有问题。第6步的提交构建验证是在一个干净且受控环境中执行与第步个人构建相同的内容，以确保开发人员的本次提交是完整且无质量问题的，没有遗漏。

2. 验证一定要做两次么？
是的，因为验证的环境是不一样的

3. 如何确保在提交前执行个人构建？
代码仓库通常费用 webhooks的配置，提交的时候触发配置允许。

4. 每次构建应该含哪些内容？

(1）构建结束后生成的二进制包是否包含了正确的内容，例如配置文件的完整性。

(2）这个构建结果是否能够正确安装井正常启动运行起来。

(3）启动后最基本的功能是否可以使用，如用户登录等。

对于一个团队并不是安装部署了一个持续集成服务器，每天用它进行自动化编译打包，就说明团队正在使用持续集成实践。要真正做到持续集成，获得最大的持续集成收益，需要做到以下六个点：

(1）主干开发，频率提交代码。

(2）每次提交都是完整有意义的工作。

(3）提交构建阶段在一定时间之内完成。如10分钟

(4）提交构建失败后，立即修复：且其他人不得在修复之前提交代码。

(5）应该在 10分钟内修复失败，否则回滚引起失败的代码。

(6）自动化构建成功后，团队对软件质量比较有信心。

什么是主干开发？

就要谈到；分支策略与部署流水线的方法：

1、主干开发主干发布

2、主干开发分支发布”策略

3. 分支开发主干发布策略

4. 多组件集成策略

以上的四种持续集成模式仅是最基本模式。
主干开发：可以是其中一种，在实际软件产品生命周期中，根据团队规模、产品形态、组件化程度与发布策略的不同，也可以是上述种模式的组合。

完整的提交代码: 这涉及到了每个独立的开发需要应用的理念，六步提交法：

(1）检出最近成功的代码：工程师开始工作时（例如工作日早上刚刚开工认领了一个新的开发任务）就要将最近一次构建验证成功的代码版本从团队的开发主干上检出（ checkout ）到自己的开发工作区中。

(2）修改代码：在个人工作区中对代码进行修改（包括实现产品新功能的代码，编写对应功能的自动测试用例）。

(3）第一次个人构建：当开发工作完成井准备提交时，首先执行个自动化验证集，对自己工作区的新代码执行第次个人构建（有时也被称为本地构建），用于验证自己修改的代码质量是否达标。

(4）第二次构建：从“检出代码”到“第二次个人构建完成”这段时间内，很可能在开发主干上有其他成员已提交了新代码，并通过了持续集成的质量验证。此时，就要将这个版本的代码与自己本地修改的代码进行合并（merge ），然后再次执行第二次质量验证，确保自己的代码与其他人的代码都没有问题

(5）提交代码到团队主干：当第二次个人构建成功以后，提交代码到团队开发主干。

(6）提交构建：持续集成服务器发现这次代码变更，立即开始执行提交构建，运行自动化质量验证。如果这次构建失败，则应该立即着手修复，并马上通知团队成员，禁止其他团队人员再向团队开发主干提交代码，并且不要检出这个版本。

持续集成的速度和质量的权衡

次级构建：

自动化测试数量定会越来越多，运行时迟早会超过我能够忍耐的极限。那么，如何既能得到质量反馈，又能兼顾开发人员的工作时间效率呢？这种方法就是Martin owl 在《持续集成》一文提到的次级构建（ Se on ary Build ）

多人同时提交的构建：

如果次级构建运行时间长（例如30分钟以上），当多人连续提交代码时，很容易出现提交构建均已经运行完成，但前面的次级构建还没有结束，仍旧在运行的情况。这时候，应咳如何处理呢？可能出现下图这样：

解决方法：就是多人同时提交然后进行次级构建，不用每个人提交一次就触发一次次级构建。

云平台的威力：

即：比较浪费资源的构建，放入到云资源中完成。

快速建立团队的持续集成实践

1. 构建脚本化，搭建持续集成框架

(1 ）选择款持续集成工具，并完成安装部署。大多数持续集成工具与软件开发语言无关，因此可以放心选择。目前国内比较流行的工具是Jenkins 如果你的项目是原生云应用，也可以使用持续集成云化服务。

(2 ）在该持续集成工具上建立个构建任务，可以从你的代码仓库拉取代码。

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

(4 ）修改刚刚在主持续集成工具上创建的构建任务，使其可以调用写好的这个脚本文件。

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

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

(1 ）向构建中舔加自动化测试用例。

(2 ）向构建中加入代码规范扫描。市场中有很多代码规范和健康度自动化扫描工具（如SonarQube等，当然也有很多商业化工具，Coverity等）

3、选择持续集成策略

4. 六步提交法

5、持续优化：

优化的方面可以是以下的视角：

(1）编译打包时间。通过引人各种工具，或者重新组织和优化编译找包脚本，系统模块拆分与组合等。

(2）代码分支策略。随着持续集成的深入，团队会进一步选择利于持续集成的分支策略。

(3）自动化测试用例的分层分级。随着自动化测试用例的种类及数增多，需要对不

同类型的自动化测试用例进行分层分级管理。分层是指按测试目标分层，如单元测试、集成测试和端到端的测试。分级是指按反馈速度和反馈质进行分级，在资惊不充裕的情况下，将各种测试用例放入不同的级别中（如提交构建任务和次级构建任务），并按线性方式顺序执行。

(4）试验证环境的准备。有时·测试环境的准备时间较长，耽误持续集成的时间，我就需要将试环境的准备工作进行梳理，减少人工参与，保证测试环境的准备时间。如果测试用例较多，我们可能需要同时准备多套测试环境，此时测试环境的自动化准备工作更是非常重要。

(5）优化编码规范扫描。之前我们可以使用了最少量的编译规范。随着实践的深入，团队可以逐步增加、修改和调整编码规范，使其符合团队代码质量的要求。

(6 ）生成数据报告。让每个人随时都能够方便地掌握当前的代码质量状态。

持续集成的相关工具可以参考：

33 款 GitOps与DevOps 主流系统

https://baijiahao.baidu.com/s?id=1695911577652028085&wfr=spider&for=pc

Code review工具：

https://baijiahao.baidu.com/s?id=1695911577652028085&wfr=spider&for=pc

devops 持续集成软件自动化测试

文章转载自specialApe logic，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

持续交付和devops（3）

33 款 GitOps与DevOps 主流系统

Code review工具：

评论