持续集成开篇之（一）代码发布流程

最近在网上看了不少有关CI/CD的文章，其实基本是雷同的，且内容也不是非常完善。确实，当前持续集成用到的开源工具无非还是Git、Jenkins、Ansible(Fabric)这些，不同的应该是各公司的技术框架差异，发布审核流程不同，从而使配置细节也有较大不同。接下来我要分享的一系列文章均是围绕生产版本发布、集群中间件搭建以及监控来写，并且都是这些年（2014-至今）我们一直还在用的技术（包括具体环境搭建以及前后端发布等细节），欢迎拍砖，共同探讨。

我们一直沿用的一套流程如下：

0、在公司内部搭建gitlab服务器，员工自行在公司gitlab服务器通过公司邮箱完成账号注册。

1、配置管理员在gitlab上创建project(项目或仓库)，建议按业务线或功能先分group(组)，然后再在group下创建具体的project，避免所有project混在一个group。

2、源码放在源码project；编译后可用于发布包放在可发布的project。

3、配置管理员对已注册开发人员分配权限（master、develop、Reporter等），权限可在group上分配，也可细到某个project。

4、开发人员通常只分配develop权限且在develop分支进行开发，开发人员不允许直接提交代码到master(主分支)，如需提交到master，则需要发出合并请求，由项目管理者review后决定是否合并。

5、源代码合并后，由合并者打tag触发jenkins构建出用于发布的版本包，并推送到对应发布代码的project中，同步tag，同时根据最新tag发布到测试环境。

6、在经过代码审查、集成测试、功能测试以及安全性测试等都通过后，且经产品人员确认同意发布，再使用jenkins将测试通过的tag发布到RC环境。

7、RC运行正常，产品人员确认同意发布到生产，再使用jenkins将RC通过的tag（测试和RC的tag均是同一个）发布到生产环境。

8、如果发布后出现异常，则使用jenkins按上一次正常tag进行回滚。

上述是一个较理想的流程，但实际开发过程中，一名开发人员可能身兼多职，包括编码、测试等，所以可能更通用的流程如下图1描述所示。

图1
同样，一般中小规模公司，一般只有一到两名运维人员，那么在维护上述发布框架同时，该名运维人员常备的技能如下：

0、与开发、测试、产品同学之间的和谐沟通及协调能力。

1、Gitalb搭建以及配置管理功能，包括备份恢复、邮件通知、权限分配、通过API创建project、Webhooks、tag（标签）规范化并实现自动生成tag等常用维护操作。

2、Jenkins环境搭建以及配置管理功能。包括插件安装、权限分配、邮件通知、脚本创建job、参数化构建等。

3、脚本编写能力，包括Shell、Fabric或借助Ansible完成代码编译、推送、发布（回滚也是发布）等。

4、日志集中收集，如配置syslog-ng和ELK，个人更倾向于用syslog-ng完成集中收集，然后用ELK来展示，因为在发布过程中开发人员更习惯使用tailf来查看发布过程中是否报错以便及时回滚。

5、监控，推荐使用Zabbix+Grafana，也可使用Nagios。实现对网络设备监控（CPU、内存、温度、接口流量等）、服务器硬件监控（通过IPMI接口获取硬件故障信息）、系统监控（内存、CPU、磁盘空间和IO、负载、网卡流量、文件句柄等）、集群中间件监控（集群状态、CPU、内存使用、日志等）服务监控（进程、端口、响应状态码、日志等）、数据库监控（常用命中率指标、表空间、慢查询、日志等）、业务监控等，确保业务7*24不时不中断稳定运行。

6、集群中间件搭建以及维护能力，诸如Zookeeper、Redis、Mongodb、RabbitMQ、RocketMQ等。

7、数据库集群搭建以及维护能力，包括Oracle、MySQL。不过，现在中小规模公司基本在云上，主要用的是RDS，个人觉得阿里云RDS的性能监控可视化做得非常棒，远超AWS。

总结：干运维真得非常不容易，分分钟就会当背锅侠，请对运维好一点！
下一篇：Gitlab搭建与配置技巧