持续交付基金会[1]（Continuous Delivery Foundation，简称 CDF）前几天发布了最新的一期的 CICD 趋势报告。这份报告中的调查结果基于 SlashData 过去 8 次的调查数据，这些调查在 2020 年 Q3 度到 2024 年 Q1 的三年半时间里覆盖了全球超过 150,000 名受访者。
本文是针对部分结果的解读，结果数据来自官方的报告，解读的部分纯属个人观点。有兴趣的可以查看 完整的报告[2]。
软件交付性能的演变
软件的交付性能主要通过代码发布周期、部署频率和服务恢复时间三个关键指标来衡量，这些指标能够直观地反映出一个组织在软件开发和运维方面的效率和效果。
代码发布周期
代码发布周期是指从代码提交（例如，合并到主分支）到成功部署到生产环境的时间。
这个指标衡量团队对新功能、修复或更新做出反应的速度。较短的发布周期意味着团队能够快速地将变更推送到生产环境，对业务需求和问题做出迅速响应。
从结果中可以看出代码变更的频率从 2020 年 Q3 开始逐年降低，尤其是变更频率低于每月一次的比例越来越高。
图片
部署频率
部署频率指软件部署到生产环境的频率，可以是每日、每周、每月等。
高频率的部署通常表明高度自动化和成熟的持续交付能力。这种能力可以帮助团队减少单次部署的风险，因为每次部署的变更较小，更容易管理和修复。
图片
这个结果于代码变更的周期较一致。
图片
服务恢复时间
服务的恢复时间，这里的服务恢复是指在发生生产环境中断后，服务恢复到正常状态所需的时间。
这个指标反映了团队在面对生产环境问题时，快速恢复服务的能力。较短的恢复时间表明团队有有效的事故响应和问题解决流程。
从报告可以看到其向两个极端的发展：好的越来越好，差的越来越差。
图片
影响软件交付性能的因素
CI/CD 工具的使用软件交付性能指标存在相关性。
DevOps 技术的普及
在开发过程中使用的工具/技术排在前两名的仍然是源代码管理和 Issue 跟踪，这些技术的使用相比过去 12 个月都有所增长，除了敏捷开发管理工具和基于 AI 的代码工具。
图片
CICD 工具使用数量
CICD 工具的使用数量于软件交付性能存在一定的相关性，但并不是简单的线性关系，而是较为复杂。
单纯增加工具的数量比不会永远提升性能，关键在于工具的选择、配置以及集成度，这些都影响对自动化流程和团队的支持。相反工具数量过多，会带来集成和管理的复杂性，特别是工具间的兼容性和互操作行无法得到妥善处理时。
成功的 CICD 不仅仅是技术和工具的问题，还涉及的管理和执行，包括团队的培训、流程的涉及、反馈循环的建立以及持续的演进。
图片
小结
上面选取了报告里的部分内容，主要体现软件交付性能的变化，以及影响交付性能的因素，也是我觉得比较有意思的部分。不过，还是建议大家可以看一下完整的报告。
参考资料
[1] 持续交付基金会: https://cd.foundation
[2] 完整的报告: https://cd.foundation/state-of-cicd-2024/
