Git代码发布系统

引言

代码发布系统是互联网公司必备的运维系统，作用主要用户发布业务代码 到 业务服务器

为什么需要代码发布系统

有的同学可能说，我们公司服务器就那么一台，做个发布系统太麻烦了？ 不认同这说法

发布系统有如下好处

1. 流程管理，加上权限管理，可以在系统记录 谁 做了 什么 操作

2. 减少人工误操作影响，登录服务器本身操作就是有误操作的可能的

3. 运维自动化  为运维工作减负

4. 加快发布速度  不用人工登录N台服务器发布

5. 方便快速回滚版本

技术选型

git：代码管理工具  git使用笔记

rsync：同步代码到指定服务器

Yii2：php mvc 框架

Bootstrap3：前端框架

jquery：js库

代码发布系统

流程框架图

1. Web界面化操作，流程化管理 ，提交发布任务

2. 定时脚本 获取发布任务

3. 制定同步策略 发布代码

界面化操作，流程化管理

流程化管理在人员比较多的时候优势特别明显，人多手杂很容易出问题。所以在代码发布系统中加入流程化管理也是与时俱进

上图是我画的一个比较完善的流程图（以前公司实现过这么复杂的流程），描述如下

1. 新建开发分支

2. 本地开发并提交代码

3. 发布到测试服务器

4. 测试人员测试

5. 测试通过之后等待主管审批上线（测试没通过重走2-4步骤）

6. 发布上线

7. 产品 项目经理验收

8. 项目完成

PS：其中 1、3、6 是业务逻辑（需要脚本帮助的）， 其他都是流程控制

定时脚本  获取发布任务

通过流程控制将 发布上线 的任务 推送 队列中去了，就需要有消费队列任务的脚本，关于定时脚本我没有选择使用crontab，因为crontab最低也是从分钟开始 不满足业务需求，建议写一个常驻内存的shell，如下 每2秒运行一次

 
 
#!/bin/sh
cmd='php yii release/index'
while true
do
    if [ $(ps -ef |grep  '$cmd' |grep -v grep|wc -l) -eq 0 ];then
        eval $cmd
        sleep 3;
    else
        echo 'queue is Running';
    fi
done

脚本中 release/index 源码地址：https://github.com/apanly/dream/blob/master/console/controllers/ReleaseController.php 

关联配置

 
 
'ops_repo' => [
   "dream_blog" => [
      'title' => '博客',
      'feature' => [
         'path' => '/home/www/yii_tools/tools'
      ],
      'remote' => [
         'hosts' => [  ],
         'path' => '/home/www/yii_tools/dream',
         'ssh_param' => ' -i /home/www/.ssh/publish_rsa  www@'
      ],
      'version' => [
         '/tmp/release_version/version_blog'
      ]
   ]
]

制定同步策略 发布代码

关于同步策略 我实践过几种，根据不同的情况 使用不同的策略，以下仅是个人经验

• 单独业务服务器多余10台 少于20台  建议使用 rsync  推送 到 目标服务器（此时如果直接在目标服务器上git 操作 很慢，并且源服务器load有点高）

• 单独业务服务器少于10台  建议直接 在 目标服务器 执行git命令 （当然也可以rsync）

  
  

实例展示

（图一）

（图二）

（图三）

（图四）

• 图一：展示的是发布任务列表

• 图二：展示的是添加发布任务的操作

• 图三：展示的发布任务执行过程中所执行的指令

• 图四：是对图三的补充，因为本人博客系统很简单 没有远程（remote）服务器，只更新本地服务器，所以图四截图是原来在公司做的系统 发布远程代码的输出，对图三中的remote对象补充

PS：操作对象 version 是版本号操作，作用有两个

1. 为静态资源加上版本号，浏览器会访问重新请求资源（达到穿透浏览器缓存的作用）

2. 版本回滚

如下图

参考资料