持续部署意味着 每个经过预先定义的自动化质量门控的code变更都直接进入生产环境而不需要手动触发发布即使现在，只有 45%的组织自动化发布到生产环境,这就是为什么那些能够安全地做到这一点的团队仍然脱颖而出的原因
如果您正在使用Capacitor或Electron进行构建，您可能已经感受到这种摩擦。一个bug修复已经准备好，web层已经修复，QA已经完成，但发布仍然等待一个人的审批，一个会议，或者一个应用商店的周期。这个‘准备好’和‘发布’之间的差距是大多数交付管道的瓶颈
对于移动团队，持续部署不仅仅是后端自动化。它是关于将可以自动发布的内容与仍然受平台约束的内容分开，然后设计一个尊重两者的发布流程。对于混合应用，这通常意味着一个工作流程用于原生壳，另一个用于用户最常与之互动的web资产
目录
- What Is Continuous Deployment
- CI vs Continuous Delivery vs Continuous Deployment
- 持续部署管道的解剖
- 选择您的部署策略
- 观察性和安全回滚的重要性
- 针对Capacitor和Electron应用的持续部署
- 在CD世界中实现安全性和合规性
什么是持续部署
开发人员将支付修复合并到 main管道构建应用程序，运行自动化检查，验证结果，并且没有人点击“部署”的时候， 持续部署.
干净的定义是简单明了的 持续部署是指自动将每个通过预定义质量门槛的code变更直接发布到生产环境中，且无需人工审批步骤。持续部署与持续交付的技术差异很简单：持续交付仍然保留了人在最后的生产触发器中 Northflank在其关于持续部署和持续交付的指南中，明确指出这一区别.
每个通过的变更都将被发送。没有发布经理，没有深夜审批，没有“生产准备”按钮
这听起来很激进，直到你看到成熟团队的运作方式。他们不会首先移除最后的门槛。他们在构建可重复、测试可信、部署步骤脚本化、生产行为可见到快速捕捉回归的步骤之后，才会移除它
对于Capacitor团队来说，这很重要，因为您的发布面板被分裂了。原生二进制可能仍然需要商店审查，但您的JavaScript、CSS、内容和配置变更可以经常通过更快的路径移动。这样一来，针对Capacitor应用的实用的CI/CD工作流程 CI/CD workflow for Capacitor apps 持续部署也会改变团队行为。工程师们停止将不相关的修复打包到一个大型发布中。产品经理们停止等待“发布日”。支持团队得到更小、更容易解释的变更，而不是来自一周前更新包的神秘回归
CI vs持续交付vs持续部署
持续部署的实践
大多数混淆来自于团队说“CI/CD”时，他们实际上指的是三个不同的自动化级别。
一个工厂的类比在这里很有用。 持续集成 将零部件组装起来并检查构建是否仍然保持完整。 持续交付 将完成的包裹运送到装载货车上，准备发货。 持续部署 自动将它装载到货车上，一旦它通过了检查。
实践差异
CI 只回答一个问题：新 code 是否集成得很好？
持续交付回答一个不同的问题：这个构建是否准备好发布？
持续部署又进一步：如果它准备好了，我们为什么要等待？
成熟的关键在于最后一步。根据Forrester的全球开发运维benchmark调查的文章指出，只有45%的组织实现了自动发布到生产环境 45% of organizations automate release to production这意味着超过半数的组织在发布到生产环境之前仍然保留一些手动步骤。同一篇文章将这一差距定位为普通管道自动化和真正 持续部署采用之间的分水岭.
| Aspect | 持续集成（CI） | 持续交付（CD） | 主触发器 |
|---|---|---|---|
| __CAPGO_KEEP_0__提交或合并 | Code提交或合并 | Code提交或合并 | Code commit or merge |
| 核心目标 | 持续构建和测试 | 保持软件可发布 | 自动发布经过验证的更改 |
| 生产发布 | 不是重点 | 需要手动触发 | 自动发布质量门控通过后 |
| 需要人类参与 | 在管道后期经常需要 | 在生产之前需要 | 从最终生产步骤中移除 |
| 最佳适配 | 团队稳定工程基础 | 想要控制发布的团队 | 强大的自动化和快速恢复的团队 |
每个模型每天的感觉
CI __CAPGO_KEEP_0__
连续交付 是许多好团队长期停留的地方。它为您提供可重复的构建、自动化验证和生产就绪的工件，同时保留了人类发布决策。
实用规则： 如果审批通常发现真实问题，保留手动门控。如果审批主要是批准通过的构建，门控可能是流程表演。
连续部署 当等待的成本高于自动化的风险时，才有意义。后端服务往往比混合移动应用程序更早达到这一点。混合移动应用程序可以在原生包装之前为Web资产达到这一点。
持续部署管道的解剖学
一个工作的管道是一条信任链。一个弱点的阶段会将“自动发布”变成“自动事故”。
合并之后会发生什么
一个完整的管道通常从code进入主分支开始。从那里，系统应该通过一个可预测的序列运行，没有隐藏的操作员步骤。
- Code提交. 合并触发管道从GitHub操作、GitLab CI、CircleCI或另一个运行器中启动。
- 构建和测试. 应用程序编译、依赖项解析并运行自动测试。
- 工件创建. 管道产生一个不可变的工件来推广，如容器镜像、签名包或打包应用程序资产集。
- 预发布部署. 这个 artifact 将落地在一个行为如生产环境的环境中。
- 验证. 热Smoke测试和环境检查验证部署在将要运行的环境中是否正常工作。
- 生产部署. 如果所有门槛都通过，自动发布就会发生。
- 监控. 系统在更改发布后检查健康状况。
IBM 将连续部署描述为 CI/CD 范围的成熟端点，其中通过的自动验证允许更改在没有单独发布事件的情况下发布。它还指出，这也消除了需要专门的发布日的需求，并且可以在开发完成后几分钟内将更改发布到 IBM 关于连续部署的概述.
对于移动团队来说，一个有用的认知模型是管道并不会在部署命令成功时结束。它结束于您知道发布是健康的时刻。因此，研究 现代软件交付实践 花在验证和恢复上的时间应该与在构建速度上花费的时间一样多。
对于一个实践性的移动示例， Capacitor CI/CD pipeline 设置指南 展示了如何将这种工作流程集成到应用程序交付过程中。
如果您想看到流程的视觉效果，一个简短的导览会有所帮助：
信任自动化的重要性
难点不是构建阶段。难点是信任它们到足以移除人类在生产之前的暂停。
有效的方法：
- 快速的单元和集成检查 当核心行为出现问题时会大声失败。
- 一个与生产行为非常接近的镜像环境 可以捕捉到配置问题
- Artifact immutability so the exact thing you validated is the thing you release.
- Clear ownership when a gate fails. Someone fixes the pipeline now, not next sprint.
What doesn’t work:
- Manual QA作为有效的门控 while the pipeline pretends to be automated.
- Long-running test suites 环境漂移
- Environment drift Last-minute shell脚本
- Last-minute shell scripts known only to one release engineer.
选择您的部署策略
自动部署到生产环境并不意味着在一次发布中暴露所有用户所有变更。良好的部署策略是团队如何在不冒险的情况下实现连续部署的速度。
减少爆炸半径的策略
不同的模式解决不同的问题。
蓝绿部署 保留两个环境。一个环境为用户服务，另一个环境保存新版本。验证后，流量切换。这对于需要干净切换和快速回滚的场景非常有用。
金丝雀部署 将小部分用户或流量发送到新版本。健康状况良好时，扩大 rollout。如果不良，回滚之前问题不会广泛传播。
滚动部署 批量更新实例。它在服务环境中很常见，逐渐替换容量比维护双重堆栈更简单。
__CAPGO_KEEP_0__ 分离部署与发布。Code可以在特性关闭的情况下达到生产环境，直到产品、支持或工程团队决定暴露它。
阶段性发布 尤其适用于移动和桌面应用。您可以将构建或OTA更新推送给beta用户、内部人员或特定客户组，然后在验证后扩大曝光。
实践中的选择
GitLab的CI/CD指南强调了一个关键点：准备度比术语更重要。决定移除手动生产门控的依赖于测试、可观察性和回滚能力的成熟度，正如GitLab的讨论中所提到的 CI/CD运维准备度.
以下是每个选项适用场景的简要概述：
- 选择蓝绿 在无法接受停机的情况下，且可以维持并行环境时选择蓝绿。
- 选择金丝雀 当变更涉及风险逻辑、用户流程或外部集成时选择金丝雀。
- 选择滚动发布 当基础设施简单性比即刻切换更重要时,选择滚动发布。
- 选择特性标志 当code准备就绪之前,业务还没有准备好时,选择特性标志。
- 选择分阶段用户发布 当不同用户组需要不同级别的暴露时,选择分阶段用户发布。
部署策略是一种风险控制,而不是复杂性的标志。
对于Capacitor和Electron应用,分阶段发布和特性标志通常起到最大的作用。它们与混合团队的发布方式相匹配。您可以快速更新共享的Web层,先在一个渠道中暴露它,并在监控数据看起来清洁之前延迟更广泛的发布。
可观察性和安全回滚的重要性
没有可观察性的连续部署就是猜测。您可以自动化发布,但除非系统在更改发布后告诉您发生了什么,否则您无法自动化信心。
发布后要关注什么
监控告诉你一个已知指标是否超过了阈值。可观性更进一步。它为工程师提供了足够的上下文，使他们能够在生产中出现奇怪情况时提出新问题。
通常，这意味着监视：
- 日志 应用程序错误、失败的作业和意外边缘情况
- 指标 延迟、错误率、崩溃模式和服务健康
- 跟踪 只在特定部署路径之后才会降级的请求
这些可见性应该直接连接到您的部署事件。 当一个发布开始引起问题时，应急工程师需要立即与时间相关联，而不是在单独的系统中搜索。改进此工作流程的团队往往从专注于 事件响应自动化工具中借鉴了想法，因为在实践中，发布恢复和事件处理重叠得很厉害。
回滚需要成为常规
回滚是“持续部署”故事中很多地方会出现问题的地方。如果回滚依赖于部落知识、senior工程师醒来、或是最后稳定版本的完美记忆，那么你还不够准备。
一个可用的回滚过程有几个特点：
- 它是快速的。 工程师可以在一步或是自动规则中恢复最后一次好的状态。
- 它是经过测试的。 回滚不是理论上的。团队已经在测试环境或是受控生产环境中进行过实践。
- 它是可观察的。 你可以确认被回滚的版本解决了问题。
- 它是有范围的。 你可以回滚一个服务、一个特性标志、或是一个更新通道而不影响其他工作。
对于混合应用团队来说，回滚有额外的重要性，因为移动用户可能会在应用重启或刷新之前继续运行一个坏的更新。一个基于通道的回滚计划通常比一个通用回滚计划更安全。因此， CI/CD工作流程中的回滚策略 成为实际的，而不是理论的。
快速部署只有在恢复速度快于用户影响时才是有利的。
Capacitor 和 Electron 应用程序的连续部署
混合应用需要不同的思维模式。如果您将 Capacitor 或 Electron 应用程序视为后端服务，则会错过两个重要的发布跟踪。
两个发布跟踪，而不是一个
混合应用具有 本机外壳 和 web层.
本机外壳包括平台包装器、插件、权限、签名和商店分发包。如果您更改本机 code、插件行为、权限或打包详细信息，则会返回到应用程序构建、签名和商店提交的世界。
web层不同。您的 HTML、CSS、JavaScript、内容和一些配置通常可以在更紧凑的循环中移动。这种应用程序部分最常被产品团队改变，这也是连续部署创造的最大实际利益所在。
本次拆分的原因是，移动团队应该停止问“我们是否有持续部署？”并开始问两个更好的问题：
- 是否可以可靠地自动化原生构建和提交？
- 是否可以安全地持续部署已安装应用程序的网页资产？
对于许多Capacitor团队来说，第一个问题的答案是“部分”。第二个问题的答案可以是“是”，如果更新路径设计得合理的话。
实用的混合发布模型
可行的模型如下所示。
第一条路径：原生发布
使用CI构建iOS、Android或桌面包裹，shell发生变化时。 运行原生测试、签名步骤和分发自动化。 保持这个管道强大，但不要假装它像纯Web发布模型一样行为。
第二条路径：网页资产发布
当变化存储在共享Web应用程序中时，让CI构建Web包裹，运行测试，签署发布负载并发布到滚动频道，如内部、beta或生产。 这样就可以关闭应用程序最快移动部分的闭环。
典型的运营模式是：
- 开发人员合并了Web修复。
- CI构建了Web资源。
- 自动化测试和验证检查通过。
- 首先将捆绑包签名并发布到受限通道。
- 可观察性确认健康采用和没有主要回归。
- 同样的捆绑包被推广更广。
实时更新平台成为现代混合应用的连续部署策略的重要组成部分。它们处理验证的Web捆绑包的分发到安装的应用程序，而不必等待每次全native发布。一个选项是 Capgo，它提供了签名的即时更新、基于通道的发布、CI/CD集成和回滚控制Capacitor和Electron工作流。
关注的运营细节不是工具名称。它是关于通道、签名、分阶段发布和回滚的纪律。如果您的团队可以立即将Web捆绑包推送给每个用户，但无法解释哪个版本到达了哪个设备，您已经创建了速度而没有控制。
对于将其集成到自动化的团队来说 how CI/CD tools trigger OTA updates CI/CD工具触发OTA更新的方式是关键连接点。您的构建系统不仅应该产生工件。它应该决定更新去哪里、在什么条件下以及如何回滚它如果需要。
For hybrid apps, continuous deployment usually means continuous deployment of the web layer first, and disciplined automation of the native layer second.
CD环境下的安全性和合规性
安全团队经常听到“自动发布生产环境”并且认为风险上升了。在实践中，一个良好的管道可以提高控制，因为它用可重复的政策替换了未经文档的人类步骤。
即使是快速交付，也可以被控制
安全的CD设置推迟了安全检查。静态分析、依赖扫描、工件签名和政策检查应该在管道中，而不是在单独的发布混乱中。如果一个构建违反了一个规则，它不应该继续前进。
这个模型也创建了一个更干净的审计记录。仓库显示谁修改了什么。管道显示哪些检查运行了。部署系统显示什么到达了生产环境并且是什么时候。这通常比一个基于手动批准、聊天消息和共享发布脚本的过程更容易辩护。
审计人员通常关心什么
大多数审计人员不关心一个人类点击了发布按钮。他们关心的是组织是否可以证明控制。
这通常会归结为几个问题:
- 发布之前是否对更改进行了审查和验证?
- 你能证明谁批准了code路径或政策吗?
- 你能证明工件在验证之后没有被修改吗?
- Can you identify which users or channels received the update?
- Can you revoke or roll back a bad release quickly?
对于在已安装的移动应用中部署Web更新的移动团队来说，签名载荷、通道权限和版本历史非常重要。这些控制帮助团队在保持快速交付的同时满足内部安全审查的要求。如果您处于这样的环境中， CI/CD中的OTA更新，带有安全性和合规性保护栅栏 是正确的运营模型。
如果您正在部署Capacitor或Electron应用，并希望找到一种实用的方式来持续部署带有签名更新、滚动发布通道、可观察性和回滚控制的Web层，请查看 Capgo。它适用于混合应用交付的部分，应用商店的时间表对于日常修复太慢了。
