AppStack应用交付 VS Flow流水线

背景信息

传统的 DevOps 平台虽然提供了一站式工具链，但在实际应用中，很多中大型研发团队发现其灵活性过高，难以有效管控研发规范。为了解决这一问题，我们推出了 AppStack 应用交付平台。AppStack 提供了以下能力：

1. 企业将研发资产托管到代码库和制品库，通过分支保护和制品晋级机制来管理代码和制品规范。

2. 另一方面，企业会利用流水线工具，按照研发的各个阶段，定义成多条流水线，例如：开发流水线、测试流水线、生产流水线，在每条流水线定义好要执行的步骤，比如：单元测试、代码扫描、自动化扫描等。

3. 最后，企业会将这些代码库、制品库和流水线都定义成模板，后续团队都基于这些模板来创建代码库、制品库和流水线，这样自然而然研发规范就建立起来了。

对于小微团队，现有的研发协同工具已经能够较好地满足需求，但对于中大型研发团队而言，这些工具过于灵活，难以支撑研发规范的落地。因此，我们推出了基于 Flow 流水线工具的 AppStack 应用交付平台。AppStack 在 Flow 的基础上，为中大型团队提供了更多的额外能力，以更好地支持研发规范。

以应用作为研发工作的主入口

应用，是一个可独立交付的对外提供服务的单元，在研发态，通常对应一个到多个功能模块，关联一个代码库；在运行态，通常对应一个微服务。云效 AppStack 以应用视角建立这个应用相关的代码、配置、团队、环境、应用从开发到部署上线的流程、以及额外的管控策略等。每个应用都有确定的归属团队，由这个团队负责其开发、测试、部署、运维等一系列流程。

流水线挂在应用下，按环境编排

常见的组织形式有两种：

• 一种是以 Jenkins 和云效 Flow 为代表，每条流水线都是独立的，通过建立分组和标签人为地进行分类；

• 另一种是以 Gitlab 和 Travis 为代表，流水线是属于代码库的，每个代码库可定义自己的流水线。

当团队达到一定的规模之后都有许些问题。1.流水线太多造成管理难的现状；2.当代码库为大的仓库，包含多个应用代码，或者从代码提交到部署要经过多个频率不同的阶段时，流水线与代码库之间很难一一对应，常常需要做很多妥协。

AppStack提供了另一种流水线组织方式：按应用组织流水线为维度。这种方式并不只是简单将多条流水线按应用分组到一起，而是将流水线直接作为应用的一部分。应用中的流水线，其代码库唯一的，这就避免了流水线影响其它应用。同时，AppStack 统一了应用的部署，且在流水线的创建上可以通过模板做全局管控，将发布准入等卡点内嵌到了流水线中，由团队管理员统一管控，从而保证了发布的安全可控。

提供多环境管理、部署观测、版本管理能力

服务上线需要涉及到多套环境进行功能验证。在云化基础设施中，环境内部的资源会频繁变化（例如，弹性扩缩容时刻都有可能添加或者减少您的云主机）。这时候需要对部署流程隔离部署环境差异以及环境内频繁变化的基础设施。当需要执行一个部署时，操作人员只需要指定部署到哪个环境（即环境唯一名称），而不需要关心环境内部的任何信息，只需把部署请求分发到指定环境的K8s集群或主机上并自动执行。

AppStack 以应用视角统一管理多套环境，环境关联 K8s 集群、主机或其他云资源，通过流水线统一的「AppStack 部署」组件来屏蔽环境差异，自动化应用CI/CD流程。

AppStack支持滚动升级、分批发布和实时查看部署状态，提供统一的环境部署版本记录，帮助快速回滚。

基于应用模板批量管理

随着微服务和云原生技术的发展，一个业务系统往往由多个微服务应用组成，多个业务方向涉及几十上百应用，涉及成百上千条流水线。而一个企业下通常只有 1～2 个运维或架构师负责这些应用的配置管理，无疑带来了大量的管理和维护成本。

AppStack提供应用模板，企业可以自定义技术栈和部署架构，新应用上线时只需选择模板一键创建并初始化配置。

此外，当应用模板有修改时可以批量升级到应用。典型场景：

• 应用稳定性升级项目要求所有统一接入监控日志，需要在应用部署中增加 SkyWalking Sidecar 容器，用于日志采集、上报等。可以修改应用模板中的部署 YAML 后，批量同步到关联应用。

  

• 企业内引入安全扫描能力，安全同学将安全扫描结果作为发布流程卡点，没有通过安全扫描的应用不允许发布。通过修改应用模板中的研发流程后，批量同步到关联应用。