想简化 应用程序更新 和版本控制? 语义版本控制（SemVer） 与 Capgo的OTA更新 Capacitor 应用程序更容易和更快。这里是如何做到的:
-
语义版本控制基础: 版本使用的格式
MAJOR.MINOR.PATCH:- MAJOR: 对于重大变更。
- MINOR: 新功能，向后兼容。
- PATCH: 修复bug。
-
为什么要使用 SemVer 与 Capgo?
- 清晰的更新沟通。
- 更智能的版本管理。
- 避免依赖冲突。
- 有序的发布计划。
-
Capgo 配置 步骤：
- 安装Capgo的更新插件。
- 配置您的应用程序版本在
capacitor.config.json和其他文件中。 - 使用您的API密钥初始化。
- Use Capgo CLI 来打包和上传更新。
-
- 使用单独的频道（例如，测试“beta”版本，稳定版本“生产”）。
- 控制更新策略（自动更新补丁，手动批准重大更改）。
- 失败更新的回滚选项。
-
部署流程：
- 遵循 SemVer 规则更新版本号。
- 测试更新前必须进行彻底的测试。
- 使用 CLI 命令上传和分发更新。
Capgo 确保更新快速可靠地到达用户，提供工具来处理中断并维持稳定性。适合使用 CI/CD 工作流来自动化更新的团队。
快速提示： 始终测试更新并使用渠道来有效地管理阶段性发布。
语义版本控制 | 提升水平
Capgo 设置指南
如何设置Capgo来轻松管理OTA更新和版本控制。
初始设置步骤
首先安装 Capgo更新插件:
npm install @capgo/capacitor-updater
npx cap sync确保你的 capacitor.config.json 文件使用语义版本格式：
{
"appId": "com.example.app",
"appName": "My App",
"version": "1.0.0"
}文件使用语义版本格式:
package.json对于较旧的项目，更新版本详细信息在这些位置:version(查找android/app/build.gradle字段)versionName)ios/App/App.xcodeproj/project.pbxproj字段)CURRENT_PROJECT_VERSION)
(更新后重新配置后，初始化Capgo使用你的API密钥：
npx @capgo/cli@latest init YOUR_API_KEY快速参考表格:
| 设置阶段 | 关键操作 | 验证步骤 |
|---|---|---|
| 安装 | 安装插件并同步 | 检查 package.json |
| 配置 | 设置版本号 | 验证所有文件 |
| 初始化 | 连接到API密钥 | 连接测试状态 |
| 构建 | 创建初始包 | 确认上传成功 |
版本控制集成
Capgo 与 CI/CD 平台兼容，简化了 自动更新 简单。支持的平台包括:
如果您正在进行本地开发，为了禁用自动更新，请将以下内容添加到您的配置中:
{
"plugins": {
"CapacitorUpdater": {
"autoUpdate": false
}
}
}这确保了Capgo不会覆盖您的本地更改。 一旦您的设置准备好，请上传您的第一个版本:
npx @capgo/cli@latest bundle upload
npx @capgo/cli@latest channel set production -s default最后，在您的应用的主文件中通知原生插件关于捆绑包的健康状况:
import { CapacitorUpdater } from '@capgo/capacitor-updater';
CapacitorUpdater.notifyAppReady();这确保了您的应用已经准备好进行smooth OTA部署和版本管理。
使用语义版本号管理Capgo
版本号管理
Capgo使用语义版本号（SemVer）管理应用版本，格式为 MAJOR.MINOR.PATCH。以下是如何工作的:
- 主版本号（X.0.0): 对于破坏兼容性的更改，增加主版本号。
- 小版本（1.X.0）: 增加 MINOR 数字的新功能保持兼容性。
- 补丁版本（1.0.X）: 增加 PATCH 数字的 bug 修复不影响兼容性。
| 版本类型 | 当时需要增加 | 自动更新行为 |
|---|---|---|
| 主版本（X.0.0） | 对于破坏性API更改 | 需要手动批准 |
| Minor (1.X.0) | 对于新功能 | 可配置在 Capgo |
| 补丁 (1.0.X) | 用于修复 bug | 通常自动 |
遵循 SemVer 规则，您可以简化版本管理并确保您的部署通道中的更新更加Smooth。
版本控制指南
Capgo 允许您通过设置不同阶段的工作流程的不同通道来有效地管理部署。
-
基于通道的版本管理:通过创建用于测试和生产的独立通道来组织您的部署过程。例如：
- 使用一个“beta”通道（例如，1.2.0-beta）来测试新功能。
- 保持一个“生产”通道（例如，1.2.0）来稳定发布。
- 在解决平台特定问题时添加平台特定通道（例如，“ios-hotfix”版本为 1.2.1）。
-
更新策略配置: 使用Capgo的配置选项来控制更新的应用方式。例如：
{ "plugins": { "CapacitorUpdater": { "disableAutoUpdate": "minor" } } }此设置确保用户自动接收补丁更新，而次要和主要更新则需要手动批准。
-
版本回滚策略: 使用预发布标识符来维护清晰的回滚选项。这种方法允许您在出现问题时回滚到之前的版本，同时保持所有通道的版本一致。
这些最佳实践使得更新管理、测试新功能和维持应用部署过程的稳定性变得更加容易。
sbb-itb-f9944d2
OTA更新部署
: 一旦您的版本管理设置就绪，请按照以下步骤来有效地部署OTA更新。
更新准备
: 首先更新版本在 package.json 和 capacitor.配置文件.json确保版本遵循 SemVer 格式（主版本.次版本.修订版本）：
- Bug 修复: 修订版本号增加（例如，1.0.1 → 1.0.2）
- 新功能: 次版本号增加（例如，1.0.0 → 1.1.0）
- 重大变更: 主版本号增加（例如，1.0.0 → 2.0.0）
彻底测试您的构建并确认应用程序与服务器通信 notifyAppReady.
接下来，决定您的 更新策略. 您可以选择:
- 自动更新: 自动执行最低版本要求。
- 手动控制: 指定更新的具体版本要求。
- 频道: 使用频道进行测试和阶段性发布。
Capgo CLI 更新命令
使用 Capgo 的 CLI 部署更新非常方便。以下是如何操作:
# Initialize Capgo in your project
npx @capgo/cli@latest init [apikey]
# Upload your update bundle
npx @capgo/cli bundle upload [appId]
# Add a new distribution channel
npx @capgo/cli channel add [channelName] [appId]Capgo 确保安全部署，使用端到端加密和安全密钥管理。
“@Capgo 是一种聪明的方式来进行热 code 推送（而不是像 @AppFlow 那样花所有的钱 🙂）”
部署后，您可以通过 Capgo 的控制台监控更新。更新通常在用户打开应用程序后几分钟内就可以到达。整个过程如下：
- 应用检查更新。
- Background下载更新.
- 用户退出应用时，标记新版本为活跃.
- 下次启动时应用更新.
对于企业级部署，您可能需要集成CI/CD自动化.
“我们实行敏捷开发，@Capgo 在持续交付给用户方面至关重要！
问题解决和建议
版本管理问题
在Capgo中管理语义版本号有时会使更新部署变得复杂。为了避免覆盖开发工作，请在您的 capacitor.config.json 文件中配置:
{
"plugins": {
"CapacitorUpdater": {
"autoUpdate": false
}
}
}如果更新失败，以下是您可以采取的措施:
- 设置
autoUpdatetofalse在开发期间。 - 卸载应用程序。
- 重新安装修复版本。
- 在稳定后重新启用自动更新。
对于主要版本更新，请使用标志并监听事件以正确处理更新： disableAutoUpdateBreaking 通过结合这些配置项和良好的团队实践，您可以维护版本一致性并减少错误。 majorAvailable 团队版本控制
CapacitorUpdater.addListener('majorAvailable', (info) => {
console.log(`Major update available: ${info.version}`);
// Add your update prompt logic here
});一旦个人更新被管理，团队就需要建立强大的版本控制实践。
“在合并到主仓库之前测试每个更改将加强稳定性并避免昂贵的错误”
to
开发期间 [4]
以下是保持一致性的方法:
- 将一个 branch 定义为主仓库 作为真实来源 使用独立的 __CAPGO_KEEP_0__ 通道来开发和生产环境
- 使用独立的Capgo频道分别用于开发环境和生产环境。
- 以清晰详细的提交信息记录所有 __CAPGO_KEEP_0__ 变更
- 使用明确的和详细的提交信息记录所有code变更。
环境
| 渠道 | 自动更新 | 版本模式 | 环境 |
|---|---|---|---|
| 开发 | dev | 已禁用 | 0.x.x |
| 测试 | beta | 已启用 | x.x.x-beta |
| 生产 | 稳定 | 已启用 | x.x.x |
更新恢复步骤
即使采取了预防措施，更新也可能失败。如果发生这种情况，请遵循以下恢复步骤：
- 回滚到之前的稳定包。
- 为任何新修复增加版本号（注意：删除后版本号不能重复使用） [2].
- 在应用启动时验证更新，以确保它们按预期工作。
Capgo的更新器设计用于处理中断。例如，如果服务器不可达或更新被删除，应用将继续正常运行 [3].此外，失败的网络请求将在下一次应用启动时自动重试 [3].内置的弹性降低了停机时间并确保了更平滑的运作。
概要
语义版本控制，结合Capgo，已使Capacitor应用的OTA更新更高效。通过947.6亿次更新和1,400个生产应用使用此系统 [1],部署过程已变得更加高效81% [1].此设置允许开发人员快速推送更新并以控制的方式进行，绕过应用商店的延迟。
开发者们在说什么:
“我们在生产环境中部署了 Capgo OTA更新 in production for our user base of +5000. We’re seeing very smooth operation almost all our users are upto date within minutes of the OTA being deployed to @Capgo.” - colenso [1]
MAJOR.MINOR.PATCH版本系统使得我们能够轻松地沟通重大更新、新功能和bug修复 [5]，尤其是在通过Capgo平台管理多个每周发布的团队中尤其有用
Capgo的 加密解决方案,与CI/CD工具集成，成本也很低，节省了五年内的26,100美元 [1]，可定制的频道确保更新在正确的时间到达正确的用户
“我们实行敏捷开发，@Capgo在持续交付给用户方面是 mission-critical” - Rodrigo Mantica [1]
继续阅读如何使用Capgo OTA更新的语义版本
如果您正在使用 如何使用语义版本控制与Capgo OTA更新 为回滚和版本控制做好准备，连接它与 回滚 回滚的实施细节在 版本目标 版本目标的实施细节在 更新行为 更新行为的实施细节在 捆绑包 捆绑包的实施细节在 Capgo 实时更新 为 Capgo Live Updates 的产品工作流程。
