【以下为分享实录，有删节】
本日禀享的题目是《企业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在流水线的生命周期中（失落败、成功、停息等）关照第三方。
这样的研发架构就具备了一定的灵巧性和可扩展性，但对付企业来讲这是不足，还必须具有开箱即用的能力。
云效内置代码扫描、 安全扫描和各种自动化测试能力，并通过流水线模板串联起来 。如上图右侧所示，针对主流的开拓措辞Java、PHP、Node.js、Go、Python等供应从构建到支配发布的各种模板，可以帮助你快速开始。
模板化能力实在是推进CICD规模化落地的关键，云效不仅供应了数十种通用的模版来帮助你快速创建流水线，同时供应定制化能力，支持定制企业自有模版来管理企业持续集成和持续交付流程，将繁芜的流程通过可视化编排和结果展现，保障交付可见可控可度量。
总结：
当你已经对CICD有一定理解，怎么样更好的在组织内规模化落地呢？第一，你须要选择一款兼具灵巧性和规范性的工具平台。第二，制订适宜自己企业的研发模式，并将其固化下来；第三，研发模式的变更可以运用到已有的团队；第四，通过适当的卡点来掌握全局风险。
