持续集成 – Tech 学习之路

一、概述

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

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

优势

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

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

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

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

集成测试：针对整体产品的某个功能的测试，又称功能测试。

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

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

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

所有测试以自动化为主，少数无法自动化的测试用例，就需要人工执行。

PS：更新版本后，每一个更新点都必须测试到，如果测试覆盖率不高，进入部署阶段后，很可能出现严重的问题。

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

部署工具:Shell,Ansible,SaltStack

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

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

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

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

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

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

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

集中式版本控制系统只有一个中央数据仓库，如果中央数据仓库故障，所有的使用者都无法使用SVN，因为每次进行版本控制工作都需要与远程服务器建立通信，否则无法工作

分布式版本控制系统会将远程代码仓库完整镜像下来后，进行本地离线版本控制，每一次的提交都不依赖于远程服务器，待有网络时再与远程仓库渐近线版本同步。

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