像发布软件一样发布工作流
一次变更先作为变更集被规划、执行，然后以 0 到 100% 的权重在版本之间分配——新版本要先在一部分真实流量上证明自己，才会接管全部。
可评审的变更集、按 0 到 100% 权重在版本间切分的流量，以及可在环境之间提升的配置。
一次变更如何上线
- 以可评审的变更集形式部署 — 部署会先被规划——在改动任何东西之前你就能看到它将改什么——然后再执行或取消。每个阶段都会被审计，它所做的资源变更也会关联回来，因此一次发布读起来是一个整体，而不是一堆零散编辑。
- 版本之间的加权流量 — 把一定比例的传入事件路由到新版本，其余仍走旧版本。先放 5%，在监控视图上观察错误率，再调整比例——或者调回去，全程无需重新部署。
- 在环境之间提升配置 — 导出一个工作区的配置并导入到别处，对于已存在的内容采用明确的处理策略。预发布环境不再是你重新敲一遍生产早已知道的东西的地方。
- 按环境隔离的变量与密钥 — 同一份工作流定义会根据运行环境指向不同的端点和凭证。提升只搬动工作流的结构，不会把生产密钥一起拖进测试环境。
平台能力
- 0–100%: 每个版本的流量权重
- 规划 → 执行: 在变更落地前先看清它
- 导出/导入: 在环境之间搬运配置
可以让新版本逐步放量吗？
可以。流量以 0 到 100 的权重分配给各版本，你可以让新版本先承接一小部分真实事件，把它的错误率与旧版本对比，然后无需重新部署就双向调整权重。
部署时，那些已经在跑的执行会怎样？
版本之间是共存而非互相替换，因此一次执行会继续跑在它开始时所在的版本上。权重决定的是新事件进入哪个版本，它不会回过头去改写已经在进行的工作。
每个环境都要把工作流重建一遍吗？
不需要。配置从一个工作区导出、导入到另一个工作区，并通过冲突策略指定如何处理已存在的内容。变量和密钥仍限定在各自的环境中——搬走的是定义，不是凭证。