## 14.Nginx+Jenkins 学习自动化持续集成（中篇）

GIT版本控制的引入 以及和持续集成的重要关系

首先咱们先要解决的一个问题， 就是 为什么存在版本控制， 以及版本控制的重要的存在意义

![](assets/1593412558-404237b32139283c98f14e6ac308334f.png)

在这一个小节中，我们必须先学习一下 GIT版本控制（CVS SVN）的使用方法 以及和持续集成的重要关系

本小节的任务： 学会GIT的基本概念， 以及GIT服务器搭建方法 ，把我们的持续集成中所有涉及到的脚本代码 以及一些配置文件 都要加入对应的仓库

GIT说白了 是版本控制的一种 而所谓的版本控制， 其实也就是 通过一种方式 把代码以及配置文件 有效的管理起来 有迹可循

\[GIT大体的工作模式\]  
![](assets/1593412558-e97a72e60de8f936c64c220ff759c7fc.png)

![](assets/1593412558-2eb098b6f6f8ed56f91ab11a0a7edc6c.png)

如上图所示， GIT的基本工作原理

首先先要在服务端搭建GIT服务， 有了服务后，在创建一个仓库， 称作GIT远程仓库

用户通过 clone的方式，把远程仓库 拉取到本地一份， 变成本地仓库 ，两边在刚拉取下来的时候 是完全一致的

远程一个仓库 其实就是一个目录，仓库clone到本地后，也是同名称的 目录

用户在本地仓库所在目录中 不过执行什么操作（新增文件，修改文件，删除文件）其实都是跟GIT关联的，处于版本控制之下

仓库在刚刚创立时为空，用户需要先把本地仓库充实起来（新增我们需要的文件 进入版本控制），然后同步本地库 =>进而同步远程库

对于同一个远程仓库来说，任何一个其他的用户 都可以clone到自己本地，进行自己的修改 再推送

![](assets/1593412558-630d34ab5d1c7dd2106cf448d9c1ee10.png)

\[企业中 运维是怎么用GIT的（服务融合版本控制）\]

![](assets/1593412558-ac6bcc87304b4ab2de0f33d0b9d8e05c.png)

![](assets/1593412558-3ca707123323d3baad0f1ed4dd02fa68.png)

如上图所示，公司运维工程师 通过GIT 将线上NGINX配置文件 加入版本管理

管理的具体内容，其实就是 /etc/nginx/ （注意 这里是通过yum安装的nginx）下面的全部配置文件

GIT通过创建branch分支（一个分支 就是一个副本 一个镜像 互相独立）, 把 线上生产NGINX集群 和 一个小的 stage环境 分开

production 生产环境集群 是真正处理线上用户请求的 核心环境 ， 这里配置文件是取自 MASTER分支

stage 测试环境 是最小量的 ，一般没有用户请求，但是有一样的服务搭建（本例中 就是NGINX），用于任何改动下的 初步测试， 这里的配置文件 取自DEV分支  
b  
企业中并不是代码才需要版本控制，配置文件也一样需要， 只要是任何有可能被改动的文件，能引起故障的，都要受到版本控制的管理

当运维想修改 NGINX配置文件的时候，先把远程库NGINX.repo clone本地， 在dev分支中 任意修改 （或者 也可以直接登录 stage机器 在/etc/nginx/下， 确保在dev分支下 修改）

修改好以后，提交DEV分支，并在 stage机器上 拉取下来, 测试DEV分支 是否让nginx正常

测试没问题后，把DEV的分支新增加的内容，合并进入master分支(git merge , DEV:commit -> master)

之后，production环境把 master分支 同步到每一台nginx上

这里有几个隐藏问题：

1） master分支被更新后，如何让30台prod nginx 都更新呢？能想出几种方法？

```plain
30 => host.list 

for i in `cat host.list`
do

ssh "$i"   "cd /etc/nginx/ ; git branch | grep master ; git pull  ;  nginx -t ; server nginx reload"

done
```

2）如果发布production后，出了严重的问题，怎么立刻解决？

```perl
GIT 回退,  GIT本地仓库的回退 -> 本地文件也回退
git log --oneline -5  # git commit id
git reset --hard commit_id
```

3）如果在 30台 nginx 上 ， 切换了分支 会发生什么？

```coffeescript
/etc/nginx/ ;  git checkout dev
```

\[企业中 开发结合持续集成 是怎么用GIT的（版本发布的 起始点）\]

![](assets/1593412558-b7d624ea7febb15b1dbf64ed3315e3ef.png)

如上图所示， GIT 其实是作为 企业 持续化集成发布的 触发点

开发人员写好代码后，先提交测试分支，然后在单元测试服务器上 跑基本功能测试

没有问题后，合并测试分支 进入 主分支

持续化集成平台 是以任务和任务之间 先后顺序调度的形式 进行工作

先有第一个任务，实时检查master分支的更新，只要有了更新 就触发下一个打包任务

所谓的打包，是将开发人 希望发布的代码文件（也可能包括 开发配置文件等等）统一打成一个Linux包（RPM/DEB）

包 需要附带 人名，日期，内容

每次更新都要打一个包，但是并不一定是 每个包 都发布生产

需要发布的时候，先安装包 在灰度发布（stage 或者 preprod）

stage一般代表 没有流量的 简单功能测试 服务器  
preprod 代表有部分生产流量的 小规模集群

然后 白盒测试人员开发的程序 （代码输入输出测试 + 压力测试） 对 两个环境进行评估

Ok->继续发布生产 ， failed -> 回退灰度环境

发布生产后，需要再接上测试任务，如果失败 要全部回退

通过上面的学习内容 我们知道了 版本控制对整个研发团队至关重要 （其实对运维和测试 也很有用）  
那么咱们为了 让公司的研发团队尽快使用上GIT 运维的任务就要来了…

想用GIT 我们就得先有GIT服务 接下来的GIT\_Server的搭建方式 会很好的帮助大家 尽快在企业中把GIT服务在最短时间内 搭建起来 让开发兄弟们 点赞哦