最近在网上看了不少有关CI/CD的文章,其实基本是雷同的,且内容也不是非常完善。确实,当前持续集成用到的开源工具无非还是Git,詹金斯,Ansible(织物)这些,不同的应该是各公司的技术框架差异,发布审核流程不同,从而使配置细节也有较大不同。接下来我要分享的一系列文章均是围绕生产版本发布,集群中间件搭建以及监控来写,并且都是这些年(2014 -至今)我们一直还在用的技术(包括具体环境搭建以及前后端发布等细节),欢迎拍砖,共同探讨。
我们一直沿用的一套流程如下:
0,在公司内部搭建gitlab服务器,员工自行在公司gitlab服务器通过公司邮箱完成账号注册。
1,配置管理员在gitlab上创建项目(项目或仓库),建议按业务线或功能先分组(组),然后再在组下创建具体的项目,避免所有项目混在一个组。
2,源码放在源码项目;编译后可用于发布包放在可发布的项目。
3,配置管理员对已注册开发人员分配权限(主、开发、记者等),权限可在群上分配,也可细到某个项目。
4,开发人员通常只分配开发权限且在发展分支进行开发,开发人员不允许直接提交代码到主(主分支),如需提交到主人,则需要发出合并请求,由项目管理者审查后决定是否合并。
5,源代码合并后,由合并者打标签触发詹金斯构建出用于发布的版本包,并推送到对应发布代码的项目中,同步标签,同时根据最新标签发布到测试环境。
6,在经过代码审查,集成测试,功能测试以及安全性测试等都通过后,且经产品人员确认同意发布,再使用詹金斯将测试通过的标签发布到钢筋混凝土环境。
7, RC运行正常,产品人员确认同意发布到生产,再使用詹金斯将RC通过的标签(测试和RC的标签均是同一个)发布到生产环境。
8,如果发布后出现异常,则使用詹金斯按上一次正常标记进行回滚。
上述是一个较理想的流程,但实际开发过程中,一名开发人员可能身兼多职,包括编码,测试等,所以可能更通用的流程如下图1描述所示。
持续集成开篇之(一)代码发布流程
