持续集成

一、概述

1.持续集成

概念
集成:将分支代码集成到主干

持续集成:频繁地将代码集成到主干

优势

  • 快速发现错误
  • 节省人力成本
  • 加快软件开发进度
  • 防止分支大幅偏离主干

作用
持续集成可以简化程序员的工作,同时还可以让产品快速迭代,保持高质量产出。
流程

step1 提交代码:开发者向代码仓库提交代码。所有后续操作都始于本地代码的一次提交(commit)。
step2 1轮测试:代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并至主干,就会执行自动化测试。

测试分为:单元测试、集成测试以及端对端测试。

单元测试:针对函数或模块的测试。
集成测试:针对整体产品的某个功能的测试,又称功能测试。
端对端测试:从用户界面直达数据库的全链路测试。

PS:第一轮测试完成的是单元测试

step3 编译:编译又称构建,是指将源码转换为可运行的实际代码,比如安装依赖,配置各种资源(样式表、JS脚本、图片)等等。
step4 2轮测试:编译完成后,进行系统测试(单元测试+集成测试),若条件允许也会执行端对端测试。

所有测试以自动化为主,少数无法自动化的测试用例,就需要人工执行。
PS:更新版本后,每一个更新点都必须测试到,如果测试覆盖率不高,进入部署阶段后,很可能出现严重的问题。

step5 2轮测试:代码经过2轮测试后,当前代码就是一个可以直接部署的成熟版本。将这个版本的所有文件打包存档,上传至生产服务器。生产服务器将打包文件解包成本地的一个目录,再将运行路径的"符号链接"指向该目录,然后重新启动应用。

部署工具:Shell,Ansible,SaltStack

step 6 回滚:一旦当前版本发生问题,就要回滚到上一个版本的编译结果。最简单的办法是修改"符号链接",指向上一个版本的目录,然后重启应用即可。

2.持续交付

概念
持续交付:在持续集成的环境基础之上,将代码部署到预生产环境并交付给测试团队测试。

流程
代码开发->单元测试->合并代码->测试->手动->部署到预生产环境->交付给测试团队
目的
无论软件如何更新,它总是可以随时随地的交付。

3.持续部署

概念
持续部署是持续交付的下一步,持续部署代表代码通过评审以后,自动部署到生产环境。

流程
代码开发->单元测试->合并代码->测试->自动->部署到预生产环境
目的
代码在任何时刻都是可部署的,可以进入生产阶段。

持续部署的前提是能自动化完成测试、构建、部署等步骤。

二、版本控制系统

1.概念

版本控制系统 :将每一次文件的变化集中在一个系统中加以版本记录,以便后期查阅特定文件版本历史记录的系统。

2 .作用

  • 追溯历史文件变更
  • 多人团队协同开发
  • 代码集中统一管理

3.版本控制系统工具

  • 集中式版本控制系统(代表:SVN)
集中式版本控制系统只有一个中央数据仓库,如果中央数据仓库故障,所有的使用者都无法使用SVN,因为每次进行版本控制工作都需要与远程服务器建立通信,否则无法工作
  • 分布式版本控制系统(代表:Gitlab)
分布式版本控制系统会将远程代码仓库完整镜像下来后,进行本地离线版本控制,每一次的提交都不依赖于远程服务器,待有网络时再与远程仓库渐近线版本同步。

版本控制系统 特点
SVN 集中式版本控制系统,没有本地仓库,依赖网络
Git 分布式版本控制系统,拥有本地仓库,不依赖网络

附:思维导图

发表评论

您的电子邮箱地址不会被公开。