最近在将公司的持续集成架构做一个系统的调整，调整过程中受到了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合并。
二、下面说说我们的在上述的这一套架构中遇到的问题：
因为各种各样的原因，我们已经使用上述的架构大约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进行持续集成相关的工作，把这个过程分享给大家，仅供参考。
后面的几个分享中偏技术性多一些，主要介绍一下构建过程中遇到的一些小坑及应对方式。