云场景实践研究第76期：南京路特

人力问题。首先，在中小型企业中，技术管理者会有很强烈的想法让专门的人来处理代码合并以及审查等工作，因为经常会出现因为某次发布没有做好代码审查导致出现故障的情况。因此希望在持续集成开始的道路之前就有专门的人来解决代码审查和合并问题。

资金问题。做持续集成将会面临一大堆的工具链的构建问题，这些工具部署完成之后是会带来成本的，首先是软硬件成本，因为无论是购买云服务器还是在本地搭建物理机来运行应用，都是会产生成本的。随之而来还会产生运维成本，因为只要是软件产品都是会出问题的，出现问题时需要人工解决，而人工最终也会转变成资金成本。

时间问题。为什么说在持续集成道路上一定会遇到时间问题呢？简单而言，使用一堆工具构建持续集成的工具链，最终实践的时候就会发现工具链会天天出问题，也可能是方法论思考的不是很透彻，而这些事情是不可能在做架构之前全部都预料到的。而一旦出现这些问题就需要拿出时间解决问题，这就会造成时间成本的上升。

效率问题。路特曾经遇到过一个问题就是在需要发布版本的时候，从开发、运维到测试，都非常希望整个公司的所有人都在场。出现这样的顾虑是因为过去在发布时所设计到的面非常广泛，会涉及到测试、打包、发布以及线上环境的替换等工作，如果这个过程一切顺利，只需要测试和运维这两个岗位配合就可以了，但是事实上却会遇到一些问题，比如开发人员在开发时使用了本地定制化的工具，而服务器上没有这个工具，而测试人员在本地进行测试时也忽略了这个问题，一旦发布到正式线上就会出现Bug，这时候发布失败就需要进行回滚。而如何处理这个Bug则需要决策者参与，需要决策者来判断是这个修复这个Bug的紧要程度。而如果需要现场修复Bug时也需要开发人员在现场解决紧急的问题。这样就从两个人的岗位变成了四个人的岗位，所以持续集成如果做不好带来的最大问题就是效率的下降。

管理问题。对于中小企业而言，往往没有专人负责管理问题。往往是新员工在HR那里办完手续入职之后，到部门主管那里用邮箱开通一系列工具的账号。如果企业拥有SSO，那么可以将这一系列工具串联起来使用一个账号，但是大部分中小型企业却不会自己搭建一个SSO门户管理整个企业内部的账号问题。另外一个问题就是代码权限，SSO解决的是账号一体化登录的问题，却无法解决代码权限问题。而这就造成需要一个权限非常高的人员每天守在电脑边为团队成员管理代码权限，而如果不管理权限，给每个人都是最高权限更会出现不可预测的问题。

---

为什么选择阿里云？

通过结合阿里云平台找到敏捷开发与持续集成的平衡点

在做持续集成的时候所需要面对的第一个问题就是如何协调敏捷开发与持续集成的关系。首先的一个问题就是需求及Bug如何尽快进入开发流程。路特是一家服务于媒体大数据的B2B公司，主要提供SaaS服务，所以需求的来源非常广泛，同时Bug来源也非常广泛，不光是测试人员会发现Bug，用户也会发现很多Bug，很多的需求和Bug都可能会来源于终端用户。而终端用户提出的问题要么是通过APP内部的问题反馈收集到的工单，要么就是直接打电话过来投诉。当问题反馈已经收集到了，如何将其尽快进入到流程中呢？路特在没有使用云效平台之前有自己的一套类OA系统来解决问题，将公司内部的Bug工单和需求都做了归类汇总，处理完成之后导入到JIRA里面去。当接入到云效之后，这件事情可以在云效平台里面创建需求和Bug并形成看板，之后再实现。

第二个问题就是开发成果如何快速试错。有时产品经理或者项目经理会遇到这样一个问题：有一个产品或者功能并不确定最终市场的反馈情况，但是觉得可以试一试，希望请开发人员在一周之内开发上线并让产品经理看到最终的用户反馈报告。正是因为这样的需求，导致之前路特每年也会上一两百个小模块，而到了第二年的时候就是大浪淘沙，一两百个小模块最终只剩下三五十个，但是中间的过程成本却是存在的，因为如果不上线就不知道产品的最终反馈如何。就路特本身而言，肯定会比自己的媒体客户更懂技术，但是在对行业的理解上却不如客户，而行业客户却未必能够用技术语言将需求描述得很好，所以更需要试错的过程，这就产生了对于持续集成生态链快速响应的要求。在使用云效平台之前试错是很麻烦的，即便是实现一个小的需求往往需要经历一两周才能随着大版本一起上线。

第三个问题如何依托持续集成完成快速迭代全流程。在持续集成搭建之前，在构建部分往往是“东一榔头，西一棒槌”的状态，在构建完之后通过Jenkins的发布组件发布到服务器，之后进行统一的批量更新。在接入到云效之后，就可以通过比较好的流水线的方式解决整个持续集成的发布迭代的过程，进而简化了整个过程。从需求、Bug进入到 云效平台，到开发人员定向地针对这个需求拉分支进行单独开发、Push并触发自动构建、测试环境的自动部署等一系列流程完全都是自动完成的。

使用阿里云云效平台降低构建成本、简化维护流程

如上图所示的是现有流程的梳理。在代码的管理上，会确保系统库中有三个代码分支：dev、rc和release，这三个分支是固定的，并且不允许任何开发人员push代码，因为代码的破坏往往发生在不经意的无心之失。现有的流程中，首先开发人员会拉一个dev分支并进行命名，之后进行开发，开发完成之后合并到dev上去，所以永远不可能出现将dev拉下来修改再提交的情况。当将代码合并到dev之后，在云效平台会完成一个dev代码的构建和测试，这部分根据选择的编程语言不同会产生不同的构建效果。单元测试通过之后会推送到dev测试环境，也就是将当前代码进行构建并运行单元测试，之后通知容器集群将镜像跑起来，然后就可以拿到配好域名的URL，之后就可以进行线上dev分支的代码测试。路特现在使用了 阿里的ACM，可以帮助实现分布式的配置管理。因为容器的代码源都是一样的，但是又是无状态的，所以在代码中不可能出现写死使用的数据库或者缓存的情况，所以对于这套代码，如果可以在测试环境运行应该就能在正式环境运行，可以借助配置管理工具实现环境的区分和隔离。

这套流程执行起来是比较规范的，是通过平衡效率和风险实现的架构。但是问题是路特的产品线比较多，这就意味着整套流程需要跑四五次，所以如果不使用 云效平台则会使得成本比较高，维护也比较麻烦。

借助云效平台的持续集成进行架构优化

钉钉+云效=更高效

路特结合自身的业务痛点在架构上进行了一定的调整，通过 钉钉+云效可以完美地解决所有的问题。首先是代码权限问题， 云效接入 钉钉企业版之后，可以为新入职的员工分好组，员工就可以自动获取该组对应的Git代码。与此同时也解决了账号的问题，因为云效是一个一体化的平台，代码的构建工作全部都是在云效上面做的，使用钉钉账号就能进入云效平台，并且基于钉钉账号就能配置好代码管理权限。此外，对于流程控制而言，结合钉钉和云效开发也会非常方便。

---

迁移上阿里云后的成效

通过阿里云系列服务及本身架构上的调整，目前在持续集成方面的成本上一年大约可以节约20-25万左右。

通过与 钉钉等办公产品的有机结合，让持续集成的流程性变得更简单，且集成的过程变得更敏捷了。

多产品、多项目的持续集成通过云效的自定义流水线，可以解决原来的一些不够敏捷的问题，降低了中层成员的时间成本并提高了效率。

关于南京路特的更多实践详情： 如何破局CI工具拉锯战：探寻中小企业的持续集成之路

原文发布日期：2017-12-15

云栖社区场景研究小组成员：董普庆，仲浩。