云效(原RDC)如何耦合进我们的业务

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品。

我会把我最近3个月的使用体会分成5个部分:使用RDC的动机、PHP项目集成、JS项目集成、JAVA项目集成、Docker类项目集成这5个分支来写

因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录:

1、RDC如何耦合进我们的业务

2、如何构建一个基于Composer的PHP项目

3、如何构建一个基于NodeJS的前后端项目

4、如何构建一个基于Maven的Java项目

5、RDC + 容器服务完成持续集成


一、现有架构梳理

在没有切入RDC之前,我们公司的持续集成主要是通过以下的方式进行全流程:

应用环境: 基于Docker集群。

代码存储: 存放在 code.aliyun.com,阿里基于gitlab搭建。

构建打包: 使用Jenkins来进行构建。

上线发布: 部分通过Jenkins发布,部分通过自定义脚本实现。

我们之前的开发方式是基于微服务的方式进行开发,所以虽然按项目进行人员分组,但是具体的开发、测试、运维智能都是面向微服务,导致了代码分支的管理上有更严格的要求。我们的每一个代码库(服务,也可以理解为应用)都分为3个分支 dev、rc、release ,含义如下:

dev 开发分支: 主要用于工程师们日常开发后的合并归总,比如基于dev创建一个新分支 dev-hanmeimei 用来存放员工韩梅梅的相关代码,当韩梅梅开发完成后,提交合并到dev分支即可。原则上不直接修改dev分支的内容,防止出现污染和冲突。dev里的代码会自动的发布到日常测试环境,进行测试。

rc 预发分支: 当dev分支的内容通过测试后,从dev合并到rc,然后进行线上测试,完成预发。此分支也不可进行人为干预和修改,只接受合并请求。

release 线上分支: 正式代码,rc线测完成后合并到release分支,此分支也不可进行人为干预和修改,只接受合并请求。有一种特殊情况支持直接干预,比如线上出现了很严重的bug,再走一遍合并流程已经太迟了,直接拉release分支创建一个release-bug分支,然后把bug修复完成后直接与release合并。

_1


二、下面说说我们的在上述的这一套架构中遇到的问题:

因为各种各样的原因,我们已经使用上述的架构大约18个月以上了,所以积累下的问题特别的多,有些问题忍忍也就过去了,有些问题却逐渐带来了严重的影响。

1.成本问题

先从代码管理方式来说,因为我们的代码管理模式是dev—>rc—>release的方式,需要一层层的进行合并,而我们不能向所有技术人员开放所有分支的合并权限,那就意味着需要至少有一个人来进行代码的审查及合并工作,这是一个人力成本的问题。

然后说说硬件投入,我们之前的jenkins服务一共有3个机器组成,1个管理,2个构建。这一套2核4G内存大概一年15000元左右,对公司来说属于必要成本,谈不上贵,但也不算便宜。

随着使用逐渐发现,特定时间的代码push频率提高,原有的构建机器出现资源争抢,后来就改成了错时构建(不侦听push),每5分钟一次,对效率有着轻微的影响。

2.管理问题

因为开发负责的服务/应用不一样,从企业内部管理的角度来说,不可能给所有开发人员开启所有代码仓库的权限,那必须要有人对开发、测试人员的git权限进行维护,这一点其实很痛苦。人员离职、入职时需要把某些员工移入仓库,移出仓库,还有时需要提权/降权。我们一直没能解决这个问题,都是人肉维护git权限,比较累,效率也很低。

3.效率问题

之前说过,我们有专人对代码的合并进行审查和管理,但是因为快速迭代,导致每天会频繁的审查和接受合并。从代码安全性角度来说这是不得已而为之的一件事,低效,但是安全。

另外,在版本发布时,有些版本是自动发布的,有些产品比较重要,需要手动进行发布。这样一来,发布也需要牵扯一些精力,这个权限不可能下放给工程人员,但是放在PM或者PL手里又产生了大量的流程时间成本,目前没有很好的解决,还是人肉处理,比较累。


三、带着问题出发,通过RDC完成持续集成

留意到阿里云的RDC产品主要是之前使用过阿里云的另一个产品CRP(据说今年即将停止维护了),他同样支持类似jenkins的功能,而且无需自己提供服务器。

一开始没完全切换到CRP的原因是我们的业务需要Docker部署,CRP到中后期才对Docker完成支持,而那时我们已经切换到jenkins上去了,所以就搁置了。

1.通过RDC有效降低成本

RDC是一个阿里云提供的云服务,目前是免费的,未来即便商业化,应该也会大幅度低于自建系统的成本,不用特别担心。

它直接打通了阿里云Code可以完成触发构建。

不需要自备额外的机器进行构建。仅此一项对我来说一年至少节省1.5万元。

之前公司使用禅道等一些产品管理需求、BUG、文档等,接入RDC后它自带项目和产品管理,节约了办公这块的成本,且支持钉钉接入,手机使用还是蛮方便的。

2.通过RDC解决管理问题

代码仓库的权限问题一直使我们公司的心病,因为人员离职/入职导致需要调整每一个仓库的权限。同时我们又是微服务架构,导致一个应用可能会有N个仓库,调整起权限来简直是心累。

庆幸的是,我们公司一直是全员通过钉钉办公,而RDC支持对接钉钉及其组织架构。那么通过RDC+钉钉我们做到了下面这些事情:

1.只需要在钉钉里维护员工入职、离职即可,离职后相关项目权限自动就没了。(省心+1)

2.在RDC里为你的阿里云Code代码仓库分好git组,然后把对应的钉钉用户丢到某个组下即可完成批量授权/降权。(省心+2)

RDC接入钉钉这个功能,我和RDC&CRP团队喊了快1年,总算是支持了,这也是我觉得RDC一定能更好用的一个主要原因,产品多了、业务复杂之后你才能体会到内部管理时的碎片化有多痛苦,而RDC+钉钉我觉得能有效缓解这种痛苦。

3.通过RDC解决效率问题

通过RDC可以完成整个持续集成的工作流,并且RDC的最新版本已经可以自定义流水线了,可以有针对性的完成构建、自动部署、手动部署、开关式部署。

一些不太重要的业务,在流水线里设置成自动发布,一些比较重要的业务设置成手动发布。而且未来发布相关的操作很可能在钉钉里就能直接完成,这样一来其实已经减少了大量的中间流程,变相提高了效率。

重要的是,可以针对性的设置多个流水线,相当灵活,而且现在的构建和部署自由度很高。

另外,钉钉聊天记录可以直接转RDC的项目需求,我觉得这个功能简直好用到突破天际。


四、备注

开篇就说到这里,主要是聊一聊我们自己公司遇到的一些问题,以及为什么选择RDC。

上面写的东西,可能有一部分大家能找到共鸣,也可能看完不知所云,因为每个团队遇到的问题是不同的,感受和痛点也不同。

我不是要向大家推销RDC这个产品,那是阿里云团队的事情,我也不觉得RDC是完美的,仅仅是因为我们选择了RDC进行持续集成相关的工作,把这个过程分享给大家,仅供参考。

后面的几个分享中偏技术性多一些,主要介绍一下构建过程中遇到的一些小坑及应对方式。