__CAPGO_KEEP_0__ mobile CI/CD

一天下班时发布了一个版本。支持团队醒来后接到用户反馈，抱怨应用程序崩溃、登录失败或突然停止的支付流程。工程团队问了一个最基本的问题：是什么变化了？然后房间里变得安静。

一个人查看Git提交记录。另一个人查看CI日志。产品团队查看App Store的发布说明，内容仅仅是“bug修复和改进”。Slack中的某个人记得最后一分钟的配置调整，但没有人确定它是否在商店版本中、还是在实时更新包中、还是两者都有。这就是团队学习到，发布日志和App版本历史不是同一回事的时刻。

If your mobile team ships through the stores and also pushes code outside the store review path, your operational risk doubles unless version history is treated as a system, not a note-taking habit. Teams that have already felt the pain of review delays, rejected submissions, or unclear release provenance will recognize the pattern in this App Store 拒绝后分析. The lesson is simple: when release state is ambiguous, incident response slows down exactly when speed matters most.

你意识到版本历史的重要性时的关键时刻
- 压力下出现的运营差距
- 当历史记录薄弱时会出现什么问题
什么是 App 版本历史
- 日志是给用户的，历史系统是给运营人员的
- 每个团队都需要的最低记录
四个理由：你的 App 现在需要版本历史
App Store历史记录 vs Live Update历史记录
- 什么是Store历史记录擅长的
- Live Update历史记录改变了游戏规则
设计您的版本历史数据模型
- 从第一天开始值得存储的字段
- 一个实用的JSON示例
将其应用到Capgo
- 一个解释性的热修复工作流
- 回滚不再是猜测
从记录管理到发布控制

版本历史的关键时刻

通常，失败不是bug本身。它是看到bug的那一刻到确定引起它的确切版本之间的延迟。

一个移动团队可以承受缺陷。是什么会耗时的是不确定性。如果你无法回答哪个二进制文件被批准、哪个捆绑包被交付、哪个渠道接收了它、以及谁触发了变化，每分钟都会变成考古学。工程师们在查找提交消息。支持人员会转发截图。产品会问是否该问题影响所有用户还是只影响某个部分。没有人有一个单一的操作记录。

压力下，操作缺口会出现

存储发布历史会给你一个公开的里程碑。它告诉你一个版本存在。它通常不会告诉你关于产生它的内部事件序列的足够信息。在现代移动交付中，这是一个严重的缺口，因为应用用户运行的通常是多层次的结果：原生二进制文件、web捆绑包、资产、特性标志和配置。

公共发布说明会帮助客户。它们很少会帮助响应人员在事故中。

处理这个问题的团队不依赖于记忆或散落的工具。他们维护一个版本日志，它将每个可部署的艺术品与一个时间戳、一个源头和一个目的渠道绑定。当事故开始时，他们不是重建历史。他们是在阅读它。

当历史弱时会出现什么问题

一个弱应用程序版本历史系统会创建一个可避免的问题链：

回滚延迟： 团队争论哪个版本是最后一次被认为是可用的。
支持力度下降： 代理无法确定报告是否属于旧的商店构建还是更新的实时补丁。
后事不明： 您知道有一个回归，但您无法证明确切的发布序列。
内部信任逐渐消失： 产品、支持和工程团队停止使用相同的语言来描述“当前版本”。

这不是一个管理任务。它是生产控制。

什么是应用程序版本历史

应用程序版本历史是 应用程序的整个已发布应用程序的Git历史，不仅仅是仓库。它应该告诉你什么 code 或资产发生了变化，何时发生变化，谁发起了发布，以及发布的位置。若你的应用程序可以在商店提交外改变，历史记录必须以同样的严格程度捕捉这些变化，和原生构建一样。

应用程序版本历史的关键组成部分图表，包括更新、bug修复和功能。

许多团队仍然把版本历史视为营销艺术品。太狭隘了。一个完整的系统记录二进制文件、JavaScript打包文件、资产、配置更改、发布渠道和发布元数据在一个可审计的历史记录中。如果你在比较交付模型时，这个区别是传统版本控制和OTA更新在 __CAPGO_KEEP_0__ 之间的核心差距。 traditional versioning and OTA updates in Capacitor.

用户面向的发布说明回答，“什么新功能？”运营历史回答，“什么具体发布了，何时发布，谁发布了，以及我们如何逆向推导？”

这些是不同的工作。日志可以简洁和选择性。内部历史系统必须是完整和可靠的。在专业软件开发和实时更新管道中，维护详细的应用程序版本历史需要捕捉

什么何时, 和谁 对于每个修订以便于 accountability、错误恢复和快速回滚，正如本文所描述的 what 版本历史定义来自ITU在线.

每个团队都需要的最小记录

如果一个发布可以到达用户，那么它就需要一个历史记录。至少，这个记录应该包括：

发生了什么变化： 快照、工件引用、哈希或可比较包标识
什么时候发布： 精确的部署时间戳，而不是模糊的发布日期
谁触发了它： 一个命名的开发者、服务帐户或CI工作
它去了哪里： 生产、beta、测试或目标客户通道
如何撤销它： The previous stable revision and rollback path.

实践原则： 如果您的团队可以部署它，那么您的团队必须能够在不搜索三个系统的情况下识别它并恢复它。

成熟的应用程序版本历史也需要不可变性。团队应该能够附加注释，但他们不应该重写发布记录本身。一旦历史变得在日常情况下可编辑，它就不再在事故和审计中有用。

四个理由：您的应用程序现在需要版本历史

应用程序版本历史的论点并非抽象。它出现在支持队列、事故桥梁、合规审查和路线图决策中。跳过它的团队最终会在协调速度上付出代价。

开发人员在木桌上键入code的笔记本电脑屏幕上显示的文件系统。

事故响应速度更快

当发布出现问题时，首要的运营任务是版本隔离。哪个具体的构建或捆绑包引入了问题？哪个受众接收了它？什么是上一个已知良好的状态？

没有历史，回滚变成了一次讨论。有历史，回滚变成了一次决定。工程师可以检查最后几个发布，比较时间戳，识别出问题的更新，并将流量或用户转移到稳定版本。

速度在移动设备上尤其重要，因为商店的更正可能需要时间。如果您的应用程序还使用实时更新，那么内部历史就是停止坏补丁传播的最快方法。

审计记录不再是一次混乱

已监管的团队都知道这个痛苦。有人要求证明生产环境中发生了什么变化，谁批准了它，以及什么时候它上线。如果发布数据存储在 Slack、Git 标签、CI 项目和 App Store 备注中，答案花费太长时间，仍然感觉不完整。

一个合适的历史系统可以将混乱转化为一个查询。您可以根据日期范围、发布渠道或特性发布来拉取一个修订历史，并显示一个清晰的记录。这并不会消除治理的需求，但它为治理提供了一个具体的检查点。

支持可以回答版本特定的问题

支持不需要原始提交日志。他们需要一个可靠的方法来将用户报告与发布状态关联起来。

这通常意味着回答实用的问题，如:

这个客户是否在当前商店版本上?
他们是否接收了最新的实时包?
这个问题是否已经在后续修订中解决?
支持是否应该要求用户重新启动、更新或等待阶段发布?

当支持和工程从同一个应用程序版本历史中读取时，升级会变得更短更少情绪化。对话从“我们认为”转变为“这个设备正在使用这个修订版本。”

一个有用的参考资料关于发布机制和为什么移动更新控制很重要的嵌入式教程:

产品和工程可以获得发布可见性

__CAPGO_KEEP_0__ 不仅仅是应急情况下的版本历史。它还可以帮助团队在有据可查的情况下做出发布决策。

Android 是一个很好的例子，说明为什么版本意识很重要。 Android 的公开版本历史从 2007 年 11 月 5 日发布的 beta 版开始， 2008 年 9 月 23 日发布的第一版商业版Android 1.0 2008 年 9 月 23 日发布的第一版商业版 Android 1.0 已经发展到全球有超过 3 亿台活跃设备. 最新的大型发布版本是 Android 152024 年发布的 Android 15 in 2024, with Android 14 达到 到2024年中期，美国的35%的采用率在此期间 Android 11 在印度仍然最为普遍，采用率为 28%Android通常每年发布 一项主要更新 根据Android版本历史参考

对于产品和工程团队来说，这样的碎片化意味着发布决策不能依赖于假设。您需要对哪些应用程序版本映射到哪些操作系统现实、渠道和客户群有透明度。这样团队才能决定何时退休兼容性code,何时减慢发布速度，何时保留较旧的路径

App Store历史记录vs实时更新历史记录

在解决不同问题时，团队会遇到麻烦，因为他们认为历史记录和实时更新历史可以互相替代。

商店为您提供了主要二进制版本的公共记录。这很重要。在 iOS 上，版本历史始于 2007 年 6 月 29 日的原始 iPhone OS， 到 2024 年 9 月的 iOS 18，经过了 18 个主要版本，从 iPhone OS 1 到 iOS 18。 App Store 自 iOS 2（2008 年 7 月 11 日）开始， 而 iOS 7（2013 年 9 月 18 日）标志着重大设计转变。该平台服务于全球超过 1.5 亿台活跃设备，__CAPGO_KEEP_0__ __CAPGO_KEEP_0____CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0____CAPGO_KEEP_0__ iOS 16 大约占 美国早期2025年活跃iOS设备的32%根据此 iOS版本历史参考. 这种年度节奏对原生发布计划有用

但从操作上讲，商店仍然是一个粗略的时间线

商店历史很擅长

商店发布历史适用于一些事情：

属性	App Store / Play Store	Live Update Platform (e.g., Capgo)
受众	面向公众和合作伙伴	内部工程、支持和运维
发布单元	原生二进制	捆绑、资源、配置、目标补丁
发布频率	与提交和审查流程绑定	根据您的部署管道允许的速度
元数据深度	有限的发布相关上下文	如果设计得当，详细的运维元数据
回滚路径	通常需要另一个商店操作	可以直接回滚到之前的修订版本
调查	适合里程碑跟踪	更适合事件级别的调查

商店是平台分发二进制文件、审批和公共发布说明的正确位置。产品经理和外部利益相关者经常需要这个记录。它是可见的、稳定的和与平台政策一致的。

实时更新历史改变了游戏

如果您的团队在商店审查路径外部发布 JavaScript、资产、副本或配置更改，内部版本历史变得比公共发布说明更重要。许多移动管道现在每天都在这里生活。

一个关键限制是API深度。公共 API，如 App Store Connect，可以暴露版本历史，但它们会施加一个 历史结果的限制,即 50 个历史结果的限制，这会阻止长期分析并使合规或调查工作更加困难，正如本文所述 App Store Connect 历史限制的讨论历史限制是团队内部版本跟踪的原因之一，后者可以存储完整的修订历史并支持基于频道的发布。

如果您的事件时间线依赖于一个具有浅历史的公共 API，那么您并没有事件时间线。您有一个部分的记忆。

实时更新历史应该是私有的、可搜索的、精细的。它应该显示差异更新、频道目标、发布源、安装状态和回滚关系。它还应该让您问那些商店不能回答的问题：哪个生产热修复先只发送给beta测试者？哪个资产仅更改后发布在最后一个本机版本？哪个修订应该支持最后一个稳定捆绑包？

对于评估交付模型的团队，这个区别是实用的，而不是哲学的。应用商店更新和直接更新的比较这个比较值得一看，因为它突出了治理和速度的权衡，这些权衡会影响您的版本历史需求。

设计您的版本历史数据模型

一个有用的应用版本历史从数据模型开始。如果schema太浅，历史也会太浅。团队经常跟踪一个版本号和可能一个构建号。那样一来，一旦添加频道、补丁和回滚，就不够用了。

值得从一开始就存储的字段

您的模型应该让常见的运营问题容易回答。这些字段做了大部分工作：

版本ID 为一个独特的内部标识符，且不会改变。
__CAPGO_KEEP_0__ 为人类可读的发布标签。
为本地平台序列化。 为生产、测试、beta 或客户特定发布流程。
为准确的部署时间。 为开发者、服务帐号或 CI pipeline 初始化发布的作者。
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ 为了追溯到源代码控制。
发行说明 为了内部上下文，仅仅是公共营销文案。
artifactUrl 对于二进制或捆绑包的位置。
supersedesVersionId 为了快速回滚的原因。
状态对于草稿、激活、回滚、退役或失败。

一位专业开发者在办公室白板上绘制复杂数据库实体关系图。

如果您正在为混合应用程序工作，命名和发行标识符，这个指南将帮助您了解在Capacitor应用程序中使用版本标记 __CAPGO_KEEP_0__ 是数据模型本身的有用补充。

一个实用的 JSON 示例

以下是一个简单的形状，涵盖了大多数移动发布操作：

{
  "versionId": "ver_2025_02_18_prod_001",
  "semanticVersion": "2.5.1",
  "buildNumber": "42",
  "platform": "ios",
  "channel": "production",
  "timestamp": "2025-02-18T14:22:00Z",
  "author": "ci-release-bot",
  "commitHash": "a1b2c3d4",
  "releaseNotes": "Fixes login redirect loop and updates remote config defaults",
  "artifactType": "live-bundle",
  "artifactUrl": "bundle://releases/2.5.1",
  "supersedesVersionId": "ver_2025_02_11_prod_004",
  "status": "active",
  "rollbackTarget": "ver_2025_02_11_prod_004",
  "metadata": {
    "storeBuild": "2.5.0",
    "featureFlags": ["new-auth-flow"],
    "audience": "all-users"
  }
}

将发布记录存储起来，好像支持、安全性和工程师都需要它一样。最后，他们会需要它。

关键在于一致性。每个发布路径都应该发出相同的核心元数据，无论它来自 Xcode Cloud、GitHub Actions、Bitrise、Fastlane 还是自定义脚本。如果一个路径跳过作者身份，而另一个跳过渠道信息，历史记录就变得更难信任了。

将 Capgo 应用于实践

了解版本历史的最快方法是查看热修复工作流。

一个 bug 报告在发布后到达。问题影响生产流程，但只在已经接收到最近的 Web 包的设备上。工程师不需要进行广泛的会议。他们需要的是过滤后的修订历史、渠道和时间戳列表。

一个可解释的热修复工作流

在实时更新设置中，开发人员创建一个修复，CI 构建一个新的包，系统记录包标识、部署时间、源作业和目标渠道。团队可以通过渠道来检查历史记录，而不是猜测一个变化是否属于最后的本机提交还是一个后续补丁。

这就是像 Capgo 这样的工具 适合。它为Capacitor应用提供了捆绑历史，通过渠道跟踪更新，并支持团队在外部商店审查外推送的回滚工作流。这个Capacitor版本控制和回滚的概述 how Capgo handles version control and rollbacks 仪表板视图很重要，因为响应者没有时间从原始日志中重构发布状态

来自https://__CAPGO_KEEP_0__.app的截图

Screenshot from https://capgo.app

一个好的回滚流程不应该从“我们应该尝试哪个版本？”开始。它应该从可见的修订链开始，前一个稳定的发布版本很明显

这会在几个具体的方面改变事故响应的质量：

工程师得到确定性：

团队可以确定准确的修复候选项及其前任 支持人员得到脚本：
代理人员可以解释受影响用户是否需要重新发布还是等待阶段性修正 Agents can explain whether affected users need a relaunch or are waiting on a staged correction.
产品版本历史的包含性： 利益相关者可以看到问题是否仅限于一个渠道或发布波段。

这也改善了后事分析。

不再需要说团队“相信”修复程序引起了问题，而是可以指出序列：原生构建批准、实时包部署、错误报告、回滚触发、稳定包恢复。

从记录管理到发布控制

产品版本历史通常被视为文档。成熟的团队将其视为操作控制面板。

这意味着什么？

移动交付现在运行在两个时钟上。第一个是商店时钟，控制原生二进制、公共发布和审查驱动的节奏。第二个是实时更新时钟，控制快速修复、目标回滚和回滚速度。如果您只跟踪第一个时钟，您在移动最快的时刻就会失去视线。

Capgo 帮助 Capacitor 团队将版本历史视为发布操作的一部分，而不是仅仅是发布说明。如果您需要基于通道的实时更新、捆绑历史和回滚支持在同一工作流中，查看 Capgo.

App版本历史：开发者指南

目录