分享实录 | 企业CICD规模化落地浅析-阿里云开发者社区

分享实录 | 企业CICD规模化落地浅析

2020-05-12 4064

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 近日，阿里巴巴旗下企业级一站式DevOps平台——阿里云·云效正式开启公测，为了让广大开发者更好地了解“新云效”，《云效说码》栏目特别策划了《为云研发而生解密云效公测版专场》系列分享，邀请了5位阿里巴巴技术专家通过视频直播的方式与大家在线交流，分享云效产品的亮点和技术优势。本文整理自阿里巴巴技术专家崔力强（怀虎）的分享《企业CICD规模化落地》。

【以下为分享实录，有删节】

今天分享的题目是《企业CICD规模化落地》，因此我们不会侧重讲解CICD是什么以及怎样做CICD，而是你已经知道怎样“玩转”CICD了，要如何在一个比较大的企业中规模化地落地。

研发流程与持续交付简析

持续交付是随着互联网的迅猛发展逐渐普及的一种研发模式，它具有“快速反馈”“质量内建”“自动化”“开发自运维”等特点。

这种研发模式主要包含如上图所示的四个环节，“分支管理”“测试验证”“制品管理”和“发布”。在业界有很多工具支持这些操作，在云效产品矩阵中也有对应的产品提供相应功能。

在一个中小型的研发团队（比如5-10人），无论你是使用商业软件还是开源的工具，经过一段时间的学习，你都可以把“持续交付”做起来。但是当需要规模化落地之后，就有更多的问题需要考虑，如：

如何提高协作效率；
新团队如何快速接入；
如何进行全局风险的控制；
研发流程如何全局更新。

持续交付在阿里巴巴的规模化

接下来简单了解一下“持续交付”研发工具在阿里巴巴内部的演化历程。2009年，我们开发了自动化发布工具；2013年，建立统一构建部署平台；到了2016年我们已经有了持续交付平台，内部称为“Aone”，该产品包含了从代码开发、构建、发布等功能，以一个一站式的研发平台，这个产品到现在也一直在演进；2017年时，我们将“Aone”的核心功能开放出来，供广大开发者使用，就是我们的“阿里云·云效”。目前该产品在公测中，大家可以登录阿里云官网进行访问、使用。

下面我们介绍几个帮助阿里巴巴实现持续交付规模化落地的研发实践。

要使持续交付规模化落地，很重要的一点是需要有一套工具对研发模式进行全自动支持。 “研发模式”是指你做事情的一种方式，在这里主要是指代码发布模式以及对应的分支使用方式，比如“主干模式”，这也是持续交付比较提倡的一种研发模式。但是“主干模式”对研发人员的要求比较高，并且也不能很好的体现出当前要进行发布的内容。作为一位研发负责人，你可能会选择更灵活一些的研发模式，比如 “Aone Flow”或者 “Git Flow”等，这两种模式都需要一定的自动化工具进行支持。

其中Aone Flow是在阿里巴巴内部主流的一种发布模式及分支管理方式，我们这里简单介绍一下，感兴趣的同学可以在网上搜索相关文章了解。Aone Flow使用三种分支类型：主干分支、特性分支、发布分支。主干分支上的代码跟线上版本的代码是一致的，当你要开发一个新的功能时，就会拉取一个特性分支作为开发分支，然后在这个分支上提交代码修改。当你需要发布的时候，需要先将不同的特性分支合并为开发分支再进行发布。发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。这个过程中涉及到大量的“拉分支”“合分支”“打标签”“回滚版本”等等复杂操作，这就需要有一系列自动化工具进行支持。在阿里巴巴内部我们是通过Aone平台（即云效的内部版本）提供自动化支持的。

第二个实践是以应用为核心的一站式研发体验。“应用”是指一个服务或者微服务，可以直接对应一个代码库。以应用为中心，我们又可以串联流水线、环境管理、构建配置、部署等工具链。可以让开发人员很好的理解和打通整个研发流程，同时也可以帮助一个新团队快速上手。

上图是我们内部一个产品研发过程的截图，会有一个研发向导帮助你提交各种信息、初始化代码库、源码自动生成、申请测试环境、进行线上发布等一系列操作。这种“以应用为核心的一站式体验”非常爽，可以帮助研发团队节省很多耗费在协作上的时间，而且有了这套流程之后，只要按照向导的提示去做就好了，很少出错。

接下来，我们聊一下如何进行全局风险管控。

在部署正式环境之前，会有一个Checklist，进行安全审核、PE审核等等，我们很多对外发布的应用都会经过这样的安全审核。在前DevOps时代（2016年以前），阿里巴巴内部还是有专门的运维团队的，我们叫PE团队。在正式发布前，他们会去审核发布的时间点、配置参数等。这就是全局风险管控，这些卡点会强制在一个流程中实施，不能够取消。（当然现在已经阿里巴巴内部已经取消了PE团队，这些卡点会通过自动化工具实现）

**兼具灵活性与规范性的持续交付平台
**
通过以上几个措施，就能够在阿里巴巴内部规模化的落地CICD，当新的研发团队加入时，也不用花费太多的时间去理解这个事情，而是很快上手去操作。但是我们这一套流程也遇到一些问题，这套流程面向Web端服务是可以很好去应对的，比如我们只有一个版本的“天猫”“淘宝”，永远是面向最新版去交付的；但是随着阿里云业务的发展，特别是出现了混合云的业务，出现了面向多Region和多版本交付的情况，我们这套研发流程就有点捉襟见肘了；因为我们的研发理念是“以应用为中心”，当遇到一些跟应用无关的交付场景时这套研发流程也会显得不合时宜。

如何提高阿里巴巴持续交付平台的灵活性呢？我们最早的研发架构如上图左侧所示，底层是研发平台，上面我们做了很多“场景化”的研发组件，同时保留了一定的扩展性，比如“自定义组件”，用户可以把自己的组件接入到我们的流水线里来；也暴露了一部分API，主要只读接口，其他团队可以在这上面做一些他的场景化。

我们认为这种研发架构的灵活性和扩展能力是不足的，（如上图右侧所示）后来我们就把构建、编排、部署、制品这些能力单独拎出来，并开放对应的API，上层我们再去编纂“场景化”，而且有可能这些“场景”都不是我们开发的，而是使用这个产品的用户自己去开发，重点是我们需要将这种扩展能力暴露出来。我们还会有“自定义步骤”和“自定义组件”，这两个功能已经在云效产品中提供。同时，我们还会开发更多API、支持更多的源，也可以通过配置webhook在流水线的生命周期中（失败、成功、暂停等）通知第三方。

这样的研发架构就具备了一定的灵活性和可扩展性，但对于企业来讲这是不够，还必须具有开箱即用的能力。