本文来源于阿里云社区电子书《阿里云产品四月刊》
《阿里云产品四月刊》—提升团队工程交付能力，从“看见”工程活动和研发模式开始（1）https://developer.aliyun.com/article/1554172
基于云效平台的落地方法
我们强烈建议在落地工程交付实践之前，先把需求协作实践梳理清楚，关于这一块内容， 推荐参考：如何制定科学有效的需求流程规范。
接下来，我们会借助云效平台，按照前面章节的示例，定义应用的交付模式，并按照该 交付模式完成一个产品需求交付的完整流程。
通过应用模板定义应用交付模式
我们通过应用模板来承载团队的工程交付模式，这里我们以前面提到过的基于 feature 的持续交付模式为例。
该交付模式的特点是开发、测试均基于特性分支，集成发布均基于主干分支，属于快速 开始，快速集成，快速交付，推崇单个特性的独立开发、独立测试、独立集成于独立交 付。首先，在云效 appstack 上创建一个名为“特性驱动的持续交付模板”的应用模板。
在该模板上开启“变更 + 研发流程”服务。
按照 feature/master 两阶段的研发流程，为这两个阶段分别定义变量组，在变量组中使用不同的 k8s namespace，以及指定不同的副本数。
接下来通过模板来规范应用的部署方式，云效推崇多套环境一套编排模板的实践，差异 性的部分通过变量组来定义。
然后，我们规定每个应用都有两套环境，分别为用于 feature 开发验证的“特性验证环境”，和用于集成发布的“生产部署环境”。这两套环境与对应的变量组、部署编排和集群资源（可选）关联。
我们已经确定了应用的环境和部署策略，接下来我们规范应用的研发交付流程。
我们要求应用从开始开发到完成交付，需要经过特性验证和生产部署两个阶段的验证， 且只有经过特性验证阶段的 feature，才能进行生产部署。为了做到这一点，我们创建了一个两阶段的研发流程，分别为特性验证阶段和生产部署阶段。
在特性验证阶段，我们定义了一条包含 4 个步骤的流水线，分别为代码检视、构建、部署和测试，且规定分支为自由选择方式（可在流水线配置名称前缀为 feature- 的分支有新的代码提交自动触发）。
在生产部署阶段，我们配置了一条有 5 个步骤的流水线，分别为代码检视、构建、审核、部署和完成变更。同时限制流水线运行分支为 master，且执行时相关 feature 在特性验证阶段的执行结果为成功（云效会自动计算流水线执行时所涉及到的 feature 分支，并判断其前序阶段的执行成功与否）。
至此，我们完成了应用模板的定义，现在，让我们基于该模板来创建一个应用，并完成 一个特性的交付。
通过应用模板创建好应用后，还需要设置好应用所关联的代码仓库和相关成员。
《阿里云产品四月刊》—提升团队工程交付能力，从“看见”工程活动和研发模式开始（3）https://developer.aliyun.com/article/1554170
