1. 发布基础概念

1.1 什么是发布

在软件工程中，发布（Release） 是指将经过测试、验证的软件版本，从开发/测试环境正式交付到生产环境，使其对最终用户可用的过程。发布不仅仅是“把代码部署上去”，它通常包含版本标记、配置变更、数据库迁移、流量切换、监控验证等一系列操作。

1.2 发布与部署的区别

很多初学者容易混淆“发布”和“部署”，二者在 DevOps 语境下有明确区分：

1.3 发布流程概述

一个标准的生产发布流程通常包含以下阶段：

1. 代码冻结与分支管理——从主干创建发布分支，停止新功能合入，只接受 Bug 修复。
2. 构建与制品管理——编译 Go 二进制、构建 Docker 镜像，生成带版本号的制品并推送至制品仓库。
3. 环境部署——依次部署到测试环境、预发环境（Staging），执行集成测试与回归测试。
4. 生产发布审批——通过变更管理流程（Change Management）获得发布许可。
5. 灰度发布——按策略（蓝绿/滚动/金丝雀）逐步切换生产流量。
6. 监控与验证——观察错误率、延迟、业务指标，确认新版本健康。
7. 全量发布——确认无误后，将 100% 流量切换至新版本。
8. 发布确认与记录——标记发布完成，更新版本日志。

1.4 发布策略简介

不同的发布策略决定了新版本如何替换旧版本、如何控制风险。以下是三种最常用的策略：

1.4.1 蓝绿发布（Blue-Green Deployment）

维护两套完全独立的生产环境：蓝环境（当前运行版本）和绿环境（新版本）。发布时，将新版本部署到绿环境，验证通过后，通过负载均衡器将流量从蓝环境一次性切换到绿环境。

• 优点：切换瞬间完成，回滚只需切回蓝环境，速度极快。
• 缺点：需要双倍资源（两套环境），成本较高；数据库兼容性需提前处理。
• 适用场景：对停机时间零容忍、资源充足的关键业务。

1.4.2 滚动发布（Rolling Deployment）

逐步替换运行中的实例：每次更新一部分服务器（如 20%），新版本实例启动并验证通过后，再更新下一批，直到所有实例都替换为新版本。

• 优点：无需额外资源，逐步释放风险，可随时暂停。
• 缺点：发布周期较长；新旧版本同时在线，需保证 API 兼容性。
• 适用场景：微服务架构、容器化部署（Kubernetes 默认策略）。

1.4.3 金丝雀发布（Canary Deployment）

先让新版本服务一小部分用户（如 5%），观察指标稳定后，逐步扩大流量比例，直至全量。如果出现问题，仅影响金丝雀用户，可快速回滚。

• 优点：风险最低，可真实验证新版本在少量生产流量下的表现。
• 缺点：需要精细的流量路由和监控能力；发布周期较长。
• 适用场景：高风险变更、重大功能上线、需要真实用户反馈的场景。

策略对比总结