大禹一站式价值流交付平台(VSDP)简介
大禹是面向DevOps领域的一站式价值流交付平台(VSDP, Value Stream Delivery Platform)，全生命周期管控和赋能项目及产品的交付实施过程，并围绕价值流交付活动提供全方位的效能度量能力，以先进的生产力工具来支撑客户数字化转型过程。
GTS-系统工程技术部负责阿里云混合云项目的相关交付工作，以BA+TM两个角色参与到项目中，帮助客户进行数字化转型探索与实践。在项目交付中，我们会用阿里云原厂同学+大量生态伙伴的模式来完成项目交付，GTS的项目交付策略可以用一句话总结：“2000人实控生态伙伴15万人实现千亿级目标交付”，当然这里面的数字可能随着时间和规模的变化而变化。
在项目交付过程中，会遇到很多问题，有产品的问题、有行业知识的问题、有合作伙伴的问题，特别是现在数字化转型成为一件不得不做但又都不知道怎么做的事情的时候，客户对我们的期望很高，希望可以通过我们来完成业务增长、商业模式转型，但阿里云在数字化转型服务上，也是边交付边摸索，在最初，项目交付基本上类似救火或兜底，遇到问题解决问题，到后来开始做项目交付的标准动作，将项目的交付过程标准化、结构化、在线化。
这就需要一个平台来承载我们的方法论、交付工具等，通过平台来管控和赋能项目的交付实施过程，同时让交付状况数字化把控风险，这其实是一套体系，围绕的是整个项目交付的人、财、物、事，以此为出发点，我们团队做了一个一站式价值流交付平台——大禹，通过这个平台，将项目交付涉及到的相关要素集中起来。
上图所示为大禹平台当前具备的能力，更多能力持续开发中。
本文给大家介绍大禹流水线如何强管控业务应用的发布态，重点介绍云原生部署相关内容。
大禹流水线简介
当前项目交付模式是原厂同学带着大量 ISV 生态伙伴进行交付，对于定开类项目中的业务应用生命周期管控，每个项目玩法不同，甚至同一项目不同 ISV 玩法也不同，具体如代码的托管、代码的质量、是否单测、是否 code review、发布和变更的管控、运行环境的管控等。这种无统一规范约束的弱管控或零管控模式，极易导致项目推进不顺，甚至引发故障，另外原厂同学也无法清楚了解项目成员的工作效能，如完成需求数、fix bug 数、提交代码数、进行发布数等，容易出现人浮于事现象。
为解决上述问题，我们需要强管控业务应用的全生命周期。业务应用生命周期主要为研发态和运行态，对于研发态，大禹交付平台会提供应用创建、代码托管(也支持导入外部代码仓库)、权限管理、代码门禁、Code Review、GitOps、制品维护等基础能力，也会提供一些提效能力，如技术架构、脚手架、CloudIDE、接口和模型的管理等；对于运行态，大禹交付平台会提供 Terminal 直连 Pod、应用隔离、日志收集、业务监控、项目维度的资源管理等能力。从研发态到运行态的状态变迁，需要由流水线串联，业务应用流水线的运行即为业务应用的发布态。为了强管控发布态，大禹自研了CICD流水线，其具备如下能力:
- 为不同应用类型提供不同的标准流水线模板，前端、后端、移动端应用都有自己的标准模板，应用创建后默认使用标准模板
- 同时也提供其他模板，如制品流水线模板、扫描流水线模板等，后续视具体需求会维护更多的流水线模板，便于业务应用直接使用
- 满足自定义场景，支持为业务应用自定义流水线
- 提供公共的流水线节点，如代码扫描、质量扫描、单测运行、安全扫描等节点，供自定义流水线时拖拽复用
- 可在流水线中设置卡点，如是否存在漏洞、是否引入snapshot包、单测覆盖率是否达到要求等
- 可将业务应用发布到公共云、专有云、自建数据中心等环境
上图是一个后端应用运行标准流水线的示例，我们在标准流水线中运行了代码编译、单元测试、代码质量扫描、打包发布、构建镜像、部署等节点，最后将该应用发布到了用户设置的运行态集群中。
上图是应用总览下某个后端应用的概要页面，我们的理念是以业务应用为中心，所有对业务应用的操作都可以在一个页面上完成，不用多次切换页面。我们可以在指定的环境卡片里设置业务应用的副本数、规格、是否创建对外连接、环境变量等，可白屏化一键发布业务应用，可快速回滚业务应用到指定的镜像版本。指定环境下流水线运行完毕后，可以直接在环境卡片里看到业务应用的代码质量、单测等相关数据，可以看到其对外暴露的连接，可以对链接进行白名单访问控制等。对于运行在公共云上的业务应用，可查看业务应用日志，可直接终端连接到 Pod 中，对于运行在专有云上的业务应用，暂时不支持日志查看和终端连接。同时后续也会逐步把业务应用运行态的监控做起来，真正做到运维三板斧之可灰度、可回滚、可监控。
大禹交付平台定位是一个云原生的交付平台，业务应用部署主要基于云原生技术，如Docker、K8S等，接下来重点介绍大禹流水线之云原生部署的实现。
大禹流水线之云原生部署
GTS 当前的交付项目可分为公共云项目、专有云项目、混合云项目、其他云 or 自建数据中心项目，业务应用可能部署在公共云、专有云、其他云或自建数据中心中。当业务应用部署于公共云时网络连通问题不大，但当部署于专有云或自建数据中心时，出于安全考虑，网络往往不能随意互通，有些项目可以接受开通从专有云到公共云的单向网络访问，有些项目则要求完全隔绝为一个网络孤岛，不允许开通公网访问。不像内部有统一的基础设施，我们面临的场景多样且复杂，但不管有多复杂，总体可分为可网络互通的公共云项目、可单向访问公网的专有云项目、网络隔绝的专有云项目三类场景，接下来针对这三类场景分别介绍大禹流水线是如何支撑业务应用部署的。
场景一: 公共云项目，可网络互通
业务应用部署流程说明:
- 0：用户通过大禹研发域页面发起应用变更(发起流水线)
- 1：流水线中 push 构建好的应用 docker 镜像到大禹 Harbor 仓库
- 2：流水线中 apply 应用 CRD 到 K8S 元集群
- 3：K8S 内部机制，数据存储在 ETCD 中
- 4：部署于公共云环境中的大禹 Agent 通过监听机制监听 CRD 变化事件，并基于事件类型执行相应流程
- 5：大禹 Agent 调用运行态部署集群的接口，变更相应的应用
- 6：运行态部署集群 pull 应用 docker 镜像，变更应用
所有的公共云业务应用共用相同的大禹 Agent 来进行部署，用户需要做的仅仅是在资源管理中导入业务应用部署所需的运行态集群的配置，并且关联好导入的集群，最后业务应用在部署时会直接部署到该集群。
场景二: 专有云项目，可单向访问公网
业务应用部署流程说明:
- 0：用户通过大禹研发域页面发起应用变更(发起流水线)
- 1：流水线中 push 构建好的应用 docker 镜像到大禹 Harbor 仓库
- 2：流水线中 apply 应用 CRD 到 K8S 元集群
- 3：K8S 内部机制，数据存储在 ETCD 中
- 4：部署于专有云环境中的大禹 Agent 通过监听机制不断的监听 CRD 变化事件，并基于事件类型执行相应流程
- 5：大禹 Agent pull 公共云大禹 Harbor 中的应用 docker 镜像
- 6：将 pull 到的应用 docker 镜像 push 到专有云 Harbor or ACR 仓库
- 7：大禹 Agent 调用运行态集群的接口，变更相应的应用
- 8：运行态集群 pull 应用 docker 镜像，变更应用
该场景下对项目有如下要求:
- 客户专有云环境内申请一个 ECS，用于部署大禹 Agent:
- 可单向访问公网，主要是访问部署于公共云上的大禹服务
- 可通过 API 触达专有云环境内的相关云产品，如 ACR 镜像服务、运行态集群等
- 操作系统版本，Centos 7 以上，初始化 docker 环境依赖
- 客户专有云环境内申请三个运行态集群，分别用于日常、预发、生产三个环境的业务应用部署:
- 日常、预发环境可共用一个运行态集群，生产环境集群不建议与日常和预发混用，如果能在公共云上搭建日常和预发环境的话，也可直接使用大禹的公共集群
- 如果日常、预发、生产环境在多个 VPC，且 VPC 间网络隔离，上述申请的一个 ECS 实例可能无法同时触达这多个 VPC，可以在每个 VPC 内申请一个 ECS，然后在 ECS 上各部署一个大禹 Agent
- 客户专有云环境内申请一个 ACR or Harbor 镜像仓库，用于转储流水线上构建好的业务应用 docker 镜像
相对于公共云上的业务应用部署要略显复杂，但整体可控，只要将专有云环境内的资源申请好、大禹 Agent 部署完毕，其他环节与公共云一致。
场景三: 专有云项目, 网络隔绝
由于网络隔绝，该场景相当于场景二中 4. List & Watch 和 5. pull image 网络不通，故无法做到白屏化一键发布，必须要有人肉参与动作。该场景下可以先使用大禹的制品流水线，将业务应用的 docker 镜像构建出来，然后将构建好的 docker 镜像 pull 到本地，再倒腾到客户的专有云环境进行部署。这时虽然大禹只提供了 docker 镜像的构建，但是在流水线中依然可以进行单元测试、代码质量扫描、安全扫描等环节，对业务应用质量进行把控。
大禹云原生 DevOps 体系
什么是云原生的 DevOps 体系，我理解有两个含义，一个是我们在落地 DevOps 体系时需尽可能的拥抱云原生技术，另一个是我们需要通过技术手段引导平台上的项目拥抱云原生技术。
从上述云原生部署的场景一和场景二可知，我们基于 K8S 原生的 CRD + Operator 实现了一个部署引擎(大禹 Agent)，使用同一套代码同时支撑了业务应用到公共云和专有云环境的部署，其中基于 CRD + Operator 实现部署引擎的好处无需赘述。需要强调的一点是，我们这里 CRD 的定义也不是拍脑袋来的，是基于 OAM 的理念定义了 Cluster、Component、Application、Trait 等 CRD，希望基于 OAM 的理念来完成业务应用的部署，相关 CRD 和 OAM 的科普此处就不再赘述。
同样可知的是，除了部署引擎自身的实现是基于云原生方式外，我们也期望能够引导业务应用全面拥抱云原生，所以我们主要支持了应用的云原生部署形态，后续也会逐步扩展支持其他云原生部署形态，如 FaaS、Service Mesh 等，这么做一方面可以保证我们项目交付的技术先进性，另一方面因为云原生有公认标准，按标准来落地大禹交付平台会便利很多。
行文至此，再讲下我们的目标，全场景管控 GTS 所有研发类项目，全场景赋能所有研运角色。为了达成这个目标，我们需要落地一套契合 GTS 交付场景的云原生 DevOps 体系，仅有大禹流水线肯定远远不够，这套体系需要能够定义出什么是云原生的开发运维模式、并且能够基于云原生技术统一业务应用的运行态。
上图是我们当前正在努力落地的，会基于阿里云的技术底座来构建这套云原生 DevOps 体系，管控 + 赋能双管齐下，使其具备全生命周期管控混合云项目交付实施过程的能力，同时通过平台的标准化、规范化、技术沉淀、公共资源提供等能力提升参差不齐的 ISV 生态伙伴的平均水平和赋能项目交付过程，进而保障项目交付质量、提升项目交付效率、降低交付成本，另外也为在线平台、离岸交付的构想打下可落地的基础，构建出我们的核心技术竞争力。
如对大禹一站式价值流交付平台感兴趣，可邮件联系，zhitao.rzt@alibaba-inc.com。
