持续集成之理论篇

本文作者:CODING 用户 – 何健

持续集成 ?——?

大概数周前,突然有学长问我有没有接触过“持续集成”。

在我脑海中,这是一个陌生的词汇,于是百度了解了一番。实际上有开发和部署经验的小伙伴对持续集成不会非常陌生的,特别是那些喜欢自己写webhook的小伙伴。这篇文章来聊聊持续集成

互联网软件从开发到上线,后续迭代更新,已经有一套近乎标准的流程。其中 持续集成(Continuous integration,简称CI)则是核心流程。像「CODING 持续集成」也直接支持自定义配置流程。

概念

大师 Martin Fowler 对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。

简单说,持续集成就是指频繁自动将代码集成到主干和生产环境,比如「CODING 持续集成」所实现的功能。

目的

持续集成的目的,快速迭代,保持高质量,避免不必要的成本投入。

优点

  1. 快速定位错误,测试环节可以及时暴露问题;

  2. 避免大幅度偏离主干,借助统一的代码库;

  3. 减少不必要的成本投入,可以自动化解决的重复乏味的事情,没必要浪费人力和时间;

  4. 实际上还有很多有点,大家慢慢感受啦~

一般步骤

持续集成的核心措施, 集成到主干前, 自动化测试, 只有通过,才可以集成到主干。

成功集成到主干后,也意味着可以部署上线。 这便牵扯出另外两个相关概念,持续交付、持续部署。

这里一起看一下集成的一般步骤:

  1. 设计

  2. 开发

  3. 测试

  4. 发布

每次集成都是这样的步骤,因此持续集成会时这些基本步骤合体的循环,只要项目还在迭代,我们就会不停重复这个步骤。

持续交付 (Continuous delivery)

这里借用阮一峰老师的说法:

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

注意,持续交付在自动化测试和集成结束后,不一定会自动部署。如果有自动部署,则是持续部署的概念了。

持续部署 (continuous deployment)

持续部署(continuous deployment)则是持续交付的下一步,代码通过评审,自动化部署到生产环境。

其目的时可以随时部署,迅速投入生产阶段。

持续部署这一步,意味着产品和观众见面,但是要通过重重考验,测试、构建、部署等步骤,而且每一步都是自动的。

流程

通常如下几步:

1. 提交

就是常见的代码提交到 CODING 仓库

2. 单元测试

这个过程 通常是一个针对 commit 操作的钩子,只要由提交,就会跑自动化测试,测试通过才可以推代码到主干。(这轮测试至少要有单元测试)

常见测试:

  • 单元测试:针对函数或模块的测试

  • 集成测试:针对整体产品的某个功能的测试,也叫功能测试

  • 端对端测试:从用户界面直达数据库的全链路测试

3. 构建

第一轮测试通过,代码可以成功合并到主干,交付。

那么接下来,就要构建(build),进入第二轮测试。

但是,构建并不是绝对必须的过程,构建就是为了让源码变成可以运行的程序或代码。如果是 java、golang 项目,通常要 build 后才可以运行。但如果是 php、python,可能并没有构建过程,只要更新代码到对应的 cgi 容器的工程目录就可以了。

构建过程,我们可以自己写一些脚本和接口,挂到对应的钩子里。当然,也可以用一些成熟的构建工具:

4. 全面测试

这轮测试 ,应该是一次全面测试,除了前面提到的自动化测试,还应该包含一些无法自动化测试的部分。如果第一轮测试已经很全面(意味着前一步和第一轮测试合并了,不构建,自然无法全面测试),那么这轮测试可以作为第一轮测试的补集存在。

这里需要注意的是,测试的覆盖率。每次版本更新,更新点都应测试到位。

要素

  1. 统一的代码库

  2. 自动构建

  3. 自动测试

  4. 每个人每天都要向代码库主干提交代码

  5. 每次代码递交后都会在持续集成服务器上触发一次构建

  6. 保证快速构建

  7. 模拟生产环境的自动测试

  8. 每个人都可以很容易的获取最新可执行的应用程序

  9. 每个人都清楚正在发生的状况

  10. 自动化的部署

原则

  1. 所有的开发人员需要在本地机器上做本地构建,然后再提交的版本控制库中,从而确保他们的变更不会导致持续集成失败。

  2. 开发人员每天至少向版本控制库中提交一次代码。

  3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

  4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

  5. 每次构建都要 100% 通过。

  6. 每次构建都可以生成可发布的产品。

  7. 修复失败的构建是优先级最高的事情。

  8. 测试是未来,未来是测试

小结

从开发到上线,整体流程:

持续集成——>持续交付——>持续部署

可以用「CODING 持续集成」进行实践。

Jenkins 和持续集成什么关系

Jenkins 是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

没错,它就是一个具体的持续集成解决方案。基于 java 实现。 可以实现:

  1. 持续版本发布/测试;

  2. 监控外部调用执行的工作;

持续集成和 webhook 什么关系

说到这里,一些有php开发经验的小伙伴很容易联想到写 webhook。

没错,php 程序通常由 Http Server(比如 apache2、nginx 等)通过反响代理 fpm-cgi 或者直接内置 cgi 来执行 php 程序。这个过程更像是直接请求了 html 文档。说这里是因为,一些 php 写手为了方便更新线上代码,并不想每次都手动 scp 命令上传新的代码,特别时有时候有些代码可能是有问题的。这时候,大家都想到用版本管理,git 就是很好的选择,其中 github 和 CODING 都是不错的选择。

我们的话题是持续集成,为什么会突然扯到 php 和 git 呢?

那是因为,github 和 coding 很早就都支持了 webhook 功能。换句话说,我们可以通过开放一个特别的接口,这个接口就一个功能,执行一系列操作,每当接口被调用时,接口可以执行我们预设好的一系列任务指令。这样,我们每次写好代码,只要 push 到仓库,触发 webhook,github 等平台就会去请求我们开放的接口,用来执行更新代码和重启服务等操作。

简单说,我们给服务器上留了一个“小工”,指派给他一个接头人,接到信号就做预先安排好的事儿。

这个过程,是不是很像持续部署最后自动部署的阶段?

没错,就是这样,这个过程很可能时没有自动测试环节,直接自动交付,自动部署。

当然,如果 webhook 写复杂点,完全可以配合一些脚本命令做自己的一套 CI\CD。

总结

CODING 是一个面向开发者的云端开发平台,提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务,其中实现了 DevOps 流程全自动化,为企业提供软件研发全流程管理工具,打通了从团队构建、产品策划、开发测试到部署上线的全过程。「CODING 持续集成」集成了 Jenkins 等主流企业开发流程工具。

相关文章