15、API 部署与发布：策略与实践

API 部署与发布：策略与实践

1. 部署与发布的区别

在 API 系统的运营中，理解部署和发布的区别至关重要。部署是将一个特性完整地带入生产环境，此时系统中已经有了一个正在运行的进程，但新特性并未被激活，也不会通过与生产系统的交互来执行。而发布则是以可控的方式激活新特性，这样可以控制引入新特性所带来的风险。

Thoughtworks Technology Radar 对部署和发布的区别给出了很好的解释：在许多组织中，实现持续交付仍然是一个挑战，因此强调一些有用的技术，如将部署与发布解耦，就显得尤为重要。当提及对应用程序组件或基础设施进行更改的部署行为时，应严格使用“部署”这个术语；而当特性更改向最终用户发布并产生业务影响时，则应使用“发布”这个术语。通过使用特性开关和灰度发布等技术，我们可以更频繁地将更改部署到生产系统，而无需立即发布特性。更频繁的部署可以降低与更改相关的风险，同时业务利益相关者可以控制何时将特性发布给最终用户。

向基于 API 的架构转型的一个优势是，其解耦的特性使团队能够快速发布更改。为了实现这一优势，必须确保系统之间的耦合度保持较低水平，并将发布失败的风险降至最低。

2. 案例研究：特性标记

以遗留会议系统为例，可以通过特性标记来有效分离代码部署和发布。特性标记通常存储在运行应用程序之外的配置存储中，允许代码在特性关闭的状态下进行部署。当团队或产品所有者准备启用该特性时，可以将其打开，使应用程序执行不同的代码分支。其粒度可以是针对每个用户，也可以更粗略地全局启用特定选项。

以下是来自流行的 Java 特性标记工具 LaunchDarkly 的示例伪代码：