持续交付不仅仅是更快的管道
顶级工程组织清楚地区分 CI 和 CD。这种区别对于释放安全至关重要。
持续集成
构建和测试自动化
- 每次提交都会自动构建
- 单元测试执行
- 代码编译和 linting
- 神器生成
持续交付
安全、可重复释放信心
- 验证关键工作流程是否正常运行
- 在用户看到回归之前检测到回归
- 确保变更可以在不增加风险的情况下进行
- 跨环境提供一致的信号
持续交付是一个系统级学科，而不仅仅是具有更多步骤的管道。它需要验证变更可以持续交付而不增加风险。
为什么持续交付会大规模中断
随着组织规模的扩大，发布速度和发布信心之间的差距越来越大。
增加释放频率会增加爆炸半径
更多的部署意味着更多的回归到生产的机会。
后期测试遗漏了现实世界的故障
事后运行的测试无法防止仅在生产条件下出现的问题。
手动审批无法扩展
随着释放速度的增加，人为的门成为瓶颈。
零散的验证信号
跨工具的分散测试结果会造成盲点并导致决策缓慢。
生产环境成为测试环境
当预生产验证不完整时，用户首先发现故障。
企业持续交付实际需要什么
发布安全性和可预测性需要的不仅仅是通过测试。企业 CD 需要系统化的工作流程验证。
关键工作流程的验证
验证真实的用户旅程和业务流程是否正确完成，而不仅仅是构建过程。
确信更改能够正确执行
确保变更在现实条件下按预期进行，包括集成和边缘情况。
在用户之前检测回归
在故障进入生产之前就将其暴露出来，客户首先会遇到这些故障。
跨环境的一致信号
提供从开发到分阶段再到生产的统一验证结果。
跨团队可重复验证
跨服务、团队和组织单位实现一致的发布信心标准。
Zof 作为连续验证层
Zof 提供企业 CD 所需的发布置信层。不是 CI 的替代品。不仅仅是测试自动化。
持续验证真实用户工作流程
Zof 验证客户实际使用的工作流程，确保关键业务路径在每次更改时都能正常工作。
自动执行每一个有意义的变更
无需手动干预即可触发对拉取请求、提交、部署和计划时间间隔的验证。
早期检测回归和故障模式
在开发和阶段性问题有机会影响生产用户之前就将其暴露出来。
集成到 CI/CD 中而不中断管道
Zof 适合您现有的交付工具链。没有管道重写。开发人员的工作流程没有变化。
跨团队、服务和环境扩展
提供从单一服务到整个平台组织的一致的发布信心。
将 Zof 定位为发布置信层- 坐在 CI 管道和生产之间，验证更改是否可以安全交付。
CD 如何与其他学科相结合
持续交付是完整企业测试策略的一层。 Zof 提供的是一个系统平台，而不是一个点工具。
持续集成
构建和单元验证
代码编译、单元测试通过、生成工件
端到端测试
工作流程验证
用户旅程跨服务正确完成
持续交付
释放信心
已验证更改以确保安全部署
可扩展性测试
负载下的性能
系统大规模正确运行
生产监控
可观察性
部署后检测问题（为什么必须在部署前进行测试）
这是给谁的
持续交付信心有利于软件组织中的每个角色。
首席技术官
可预测的交付，无中断
董事会级别相信工程部门可以在不损害客户信任的情况下快速交付。
工程副总裁
充满信心地更快地发布
跨团队扩展交付速度，而无需按比例扩展风险。
平台团队
可扩展的验证基础设施
为所有工程团队提供发布信心服务。
开发运营
更少的回滚和消防演习
通过生产前故障检测减少事件响应负担。
商业
一致的交付和信任
按时交付功能，不会对客户造成可靠性意外影响。
交付验证流程
用于验证每个版本的简单、清晰的流程。
变更介绍
代码提交、PR 或部署
工作流程已验证
已验证关键路径
风险浮现
及早发现故障
自信释放
有保证地发货