初创团队持续集成的落地与实现

持续集成概念

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。 --马丁福勒

git工作分支

持续集成的前提必须要有一个健壮且分明的版本工具，毫无疑问我们这里使用 作为版本工具

这里只简单说一下各个分支的作用，想了解更多关于git工作流知识，请点击深入理解学习Git工作流

feature/* 功能分支，用于一个新的功能的开发

hotfix/* 热修复分支，用于对线上环境的bug热修复

develop/* 测试分支，测试环境对应的分支

master分支，预上线环境分支

对于hotfix和feature分支允许开发者push，对于develop和master分支只允许开发者merge。

本文原理分析图示

首先开发者完成代码后git push到gitlab服务器，通过gitlab上事先设定好的系统钩子来触发一个post请求到后端的webserver服务器。

后端webserver服务器收到请求后通过gitlabCI.py分析来源分支与项目组，然后交给不同的shell脚本处理。

通过shell脚本来更新不同环境的项目代码，如果是开发分支的话还需要配置nginx并推送访问url至钉钉。

ELK服务器监控php的项目报错日志，开发者通过查看然后及时进行debug。

webserver对git请求的具体处理图示

开发环境(dev_branch)处理流程

对于hotfix/* 或者 feature/*

git push事件 触发gitlab钩子，然后gitlabCI脚本通过条件检测，执行开发分支的shell脚本

shell脚本拉去对应的功能分支或者热修复分支，然后拷贝一份nginx模板配置文件，修改对应的域名和目录。

重载nginx配置文件并将访问连接推送至钉钉群。

gitlab服务器配置

配置服务器秘钥

添加系统钩子，并选择在什么时候触发钩子

webserver配置

配置gitlab处理脚本

这里只贴出部分代码只供参考，因为具体需求可能不同，这里就抛砖引玉。

gitlabCI.py 用于处理gitlab的事件请求

将不同的请求分发至不同shell脚本来处理

it组shell脚本

测试服务器脚本

web组shell脚本

测试环境shell更新脚本

开发分支和预算线分支与上面大致相同，这里就不贴出来了

ELK服务器配置

效果展示

gitlab合并请求推送至钉钉

nginx访问url钉钉推送

ELK展示php错误日志

总结

并非所有项目都需要自动部署，我司线上环境是通过git tag，然后使用灰度发布脚本手动发布。常用脚本在我github上:

https

:

//github.com/opsonly

我司另一个项目因为用到了java和客户端app，现在测试使用Jenkins的另一套自动化流程方案，届时我再总结出来。