Envoy Mobile 版本发布全流程：从主干开发到三件套移动产物
Envoy Mobile 版本发布全流程从主干开发到三件套移动产物【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy本文基于 Envoy 仓库中 mobile/RELEASE.md 这份发布流程文档完整拆解 Envoy MobileEnvoy 的嵌入式移动端代理组件的版本发布机制什么时候发版、如何撰写并核对 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 给出了四步操作在文件顶部新增一个Pending Release小节并包含Bugfixes:和Features:两个子节把旧的Pending Release小节改写为正式小节补上本次发布版本号与发布日期核对自上一次发布以来的全部变更都已反映进当前 release。文档给出了核对命令git log git rev-list --tags --max-count1..HEAD该命令的含义是取最近一个 taggit rev-list --tags --max-count1然后打印从该 tag 到HEAD之间所有 commit从而确保没有遗漏任何自上一发布点以来的改动如果是季度版本在 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 Androids NetworkSecurityPolicy isCleartextTrafficPermitted APIs、iOS: enable usage ofNWPathMonitorby default 等带编号条目。撰写者可以直接沿用这一既有格式追加内容。三、更新版本号VERSION 文件与 podspecRELEASE.md 要求发版时同步修改两处版本来源mobile/VERSION 文件当前内容为0.5.0单行纯版本号文档中提到的EnvoyMobile.podspeciOS 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 给出了如下执行序列创建 PR 并合入把上述改动version notes 版本号提交为一个 PR获得批准并合入main可选地等待 CI 在 main 上通过文档表述为 Optionally, wait for CI to pass on main即 CI 通过不是硬性阻塞项但建议等待以确认主干健康在 Release 页面创建 Draft release文档指向的是原 Envoy Mobile 项目envoyproxy/envoy-mobile的 releases 页面把刚写好的 release notes 复制进去并发布publish同时完成对代码的打 tag等待 artifacts 工作流运行完成tag 触发后artifacts 工作流文档中对应artifacts.yml会自动构建发布产物。运行结束后进入 workflow run 页面可看到生成的产物文件下载三个产物文件envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework回到刚才的 tag release编辑并上传这三个文件发布才算完整交付。从产物命名可以读出 Mobile 的交付形态Android 侧交付的是AAR 源码包envoy_android_aar_sources以源码形式打包便于下游按自身构建体系集成iOS 侧则同时交付CocoaPods 源包envoy_ios_cocoapods与预编译 Frameworkenvoy_ios_framework。CI 环境的配套准备Mobile 的 CI 目录 mobile/ci/ 中还包含发布与测试相关的基础设施可帮助理解产物构建的周边环节linux_ci_setup.sh/mac_ci_setup.shLinux 与 macOS 两套 CI 环境初始化脚本分别支撑 Android 与 iOS 产物的构建环境start_android_emulator.sh、start_ios_mock_server.py集成测试所需的 Android 模拟器与 iOS mock server 启动脚本test_size_regression.shMobile 场景下对包体/内存规模的回归检查。这些脚本与 RELEASE.md 描述的 artifacts 构建共享同一套 Bazel 构建体系Mobile 模块基于 mobile/MODULE.bazel 与 mobile/bazel/ 下的 Bazel 配置说明发版产物的构建与日常 CI 测试走的是同一条构建链路。五、一次发版的检查清单核对要点把 RELEASE.md 的步骤压缩成可执行的核对清单方便逐条确认步骤操作仓库落点1顶部新增Pending Release含Bugfixes:/Features:把旧 pending 小节改写为正式版本号日期mobile/docs/root/intro/version_history.rst2用git loggit rev-list --tags --max-count1..HEAD核对变更无遗漏命令行3季度版本确认 Envoy checkout 指向最新 Envoy tag并在 notes 中注明release notes4修改版本号当前仅需VERSION 文件mobile/VERSION5提交 PR → 批准 → 合入 main可选等 CI 通过仓库常规流程6创建并发布 Draft release打 tagRelease 页面7等待 artifacts 工作流完成下载 3 个产物envoy_android_aar_sources、envoy_ios_cocoapods、envoy_ios_framework8回到 tag release 上传 3 个文件完成发布Release 页面最后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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考