企业官网建设流程全解析

Envoy Mobile 版本发布全流程：从主干开发到三件套移动产物

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy

本文基于 Envoy 仓库中 mobile/RELEASE.md 这份发布流程文档，完整拆解 Envoy Mobile（Envoy 的嵌入式移动端代理组件）的版本发布机制：什么时候发版、如何撰写并核对 release notes、如何修改版本号、以及如何生成并上传 Android AAR 与 iOS 框架等发布产物。读完你可以掌握一次完整的 Mobile 版本发布操作序列，并理解其中每个步骤在仓库中的落点与校验手段。

一、开发模式：main 分支持续开发，按里程碑与上游节奏发版

RELEASE.md 的第一节明确了 Envoy Mobile 的开发模型：

• 活跃开发全部发生在main分支，不存在长期维护的 release 分支；
• 新版本在重大开发里程碑以及跟随上游 Envoy 发布时切出——文中原文为 "a new versions will be released on major development milestones and/or following upstream Envoy releases"。

这一点与 Envoy 上游的季度发布节奏呼应：当构建季度版本（quarterly release）时，文档要求确认 Envoy 的 checkout 指向了最新的 Envoy tagged release。在本仓库中，上游 Envoy 的主线版本由根目录 VERSION.txt 标识（当前为1.40.0-dev），而 Mobile 子模块有自己独立的版本文件 mobile/VERSION（当前内容为0.5.0）。也就是说，一次 Mobile 发版往往同时绑定着一个上游 Envoy 的 tag，发版记录中需要注明对应关系。

二、撰写 Release Notes：维护 version_history.rst

发布流程的核心第一步是更新 Mobile 的 release notes 文件。RELEASE.md 给出了四步操作：

1. 在文件顶部新增一个Pending Release小节，并包含Bugfixes:和Features:两个子节；

2. 把旧的Pending Release小节改写为正式小节，补上本次发布版本号与发布日期；

3. 核对自上一次发布以来的全部变更都已反映进当前 release。文档给出了核对命令：

   git log `git rev-list --tags --max-count=1`..HEAD

   该命令的含义是：取最近一个 tag（git rev-list --tags --max-count=1），然后打印从该 tag 到HEAD之间所有 commit，从而确保没有遗漏任何自上一发布点以来的改动；

4. 如果是季度版本，在 release notes 中注明所对应的 Envoy tagged release（文档以历史上 0.4.5 版本的写法作为参照）。

从当前 version_history.rst 的实际结构看，这份约定执行得非常一致：每个版本小节固定包含Breaking changes:、Bugfixes:、Features:三个子节（最新一次发布 0.5.0 还额外体现了 Breaking changes 的拆分），每条变更都带有:issue:角色标注对应的 PR 或 issue 编号（如:issue:\#2272 <2272>``），使每一条 release note 都可以回溯到具体变更。例如 0.5.0 小节中记录了 "android: respect Android's NetworkSecurityPolicy isCleartextTrafficPermitted APIs"、"iOS: enable usage ofNWPathMonitorby default" 等带编号条目。撰写者可以直接沿用这一既有格式追加内容。

三、更新版本号：VERSION 文件与 podspec

RELEASE.md 要求发版时同步修改两处版本来源：

• mobile/VERSION 文件（当前内容为0.5.0，单行纯版本号）；
• 文档中提到的EnvoyMobile.podspec（iOS CocoaPods 描述文件）。

需要说明的是，当前仓库树中已经找不到EnvoyMobile.podspec文件。这与 release notes 的记录相吻合：0.5.0 版本的 breaking changes 中明确写有 "iOS: remove support for installing via CocoaPods, which had not worked since 2020"。也就是说，RELEASE.md 中关于 podspec 的条目属于历史流程残留，在当前仓库状态下，版本号修改实际上只落在 mobile/VERSION 一处。撰写发版操作清单时应以仓库现状为准。

版本号与 git tag 的一致性校验

除了人工修改版本号，仓库还提供了自动化校验兜底。mobile/docs/build.sh 在构建 Mobile 文档时会检查git tag 与 VERSION 文件内容是否一致，关键逻辑为：

# Check the git tag matches the version number in the VERSION file. echo "${GITHUB_REF_NAME} vs $(cat VERSION)" # Given git tag does not match the VERSION file content: ...

这意味着如果 tag（如0.5.0）与 mobile/VERSION 中的内容不一致，文档构建流程会报错提示两者不匹配。从源码结构看，这一步把"改了 VERSION 但忘了对齐 tag"这类常见人为失误拦截在了构建阶段，是发布流程中值得关注的工程保障点。此外，mobile/BUILD 也将VERSION声明为构建可见文件，Mobile 的文档构建（mobile/docs/BUILD 中两处依赖//:VERSION）都直接读取它。

四、发布执行序列：PR 合入、Draft Release 与产物上传

版本号与 release notes 就绪后，RELEASE.md 给出了如下执行序列：

1. 创建 PR 并合入：把上述改动（version notes + 版本号）提交为一个 PR，获得批准并合入main；
2. 可选地等待 CI 在 main 上通过：文档表述为 "Optionally, wait for CI to pass on main"，即 CI 通过不是硬性阻塞项，但建议等待以确认主干健康；
3. 在 Release 页面创建 Draft release：文档指向的是原 Envoy Mobile 项目（envoyproxy/envoy-mobile）的 releases 页面，把刚写好的 release notes 复制进去并发布（publish），同时完成对代码的打 tag；
4. 等待 artifacts 工作流运行完成：tag 触发后，artifacts 工作流（文档中对应artifacts.yml）会自动构建发布产物。运行结束后进入 workflow run 页面可看到生成的产物文件；
5. 下载三个产物文件：envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework；
6. 回到刚才的 tag release，编辑并上传这三个文件，发布才算完整交付。

从产物命名可以读出 Mobile 的交付形态：Android 侧交付的是AAR 源码包（envoy_android_aar_sources，以源码形式打包，便于下游按自身构建体系集成），iOS 侧则同时交付CocoaPods 源包（envoy_ios_cocoapods）与预编译 Framework（envoy_ios_framework）。

CI 环境的配套准备

Mobile 的 CI 目录 mobile/ci/ 中还包含发布与测试相关的基础设施，可帮助理解产物构建的周边环节：

• linux_ci_setup.sh/mac_ci_setup.sh：Linux 与 macOS 两套 CI 环境初始化脚本，分别支撑 Android 与 iOS 产物的构建环境；
• start_android_emulator.sh、start_ios_mock_server.py：集成测试所需的 Android 模拟器与 iOS mock server 启动脚本；
• test_size_regression.sh：Mobile 场景下对包体/内存规模的回归检查。

这些脚本与 RELEASE.md 描述的 artifacts 构建共享同一套 Bazel 构建体系（Mobile 模块基于 mobile/MODULE.bazel 与 mobile/bazel/ 下的 Bazel 配置），说明发版产物的构建与日常 CI 测试走的是同一条构建链路。

五、一次发版的检查清单（核对要点）

把 RELEASE.md 的步骤压缩成可执行的核对清单，方便逐条确认：

最后，mobile/docs/build.sh中的 tag 与 VERSION 一致性检查会在文档构建时自动复核第 4 步与第 6 步的一致性，无需人工记忆。

六、小结

Envoy Mobile 的发布流程是一个典型的"主干开发 + 文档驱动"模式：发版的实质工作量集中在 version_history.rst 的维护与 mobile/VERSION 的修改上，随后通过 PR 合入、打 tag、artifacts 工作流构建、上传三个移动产物完成交付。需要注意的两点实践提示：其一，当前仓库已移除 CocoaPods 安装支持，RELEASE.md 中关于EnvoyMobile.podspec的版本号修改步骤属于历史遗留描述；其二，tag 与 VERSION 文件的一致性有 mobile/docs/build.sh 的自动化校验兜底，发版时保证两者同改即可。

【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy