如果不能度量,你将无法改进。 ——彼得.德鲁克
上述彼得.德鲁克大师的名言,让我们在直觉上产生共鸣,同时也展示了度量在各个领域的重要性。如果没有数据去定量分析我们当前在哪里、目标在哪里,那么我们将如何知道目前是否在向着正确的目标前进?下面这篇博文讲述了在持续交付过程中度量的重要性。

度量在持续交付过程中是如何起作用的?

是什么让你觉得已经达到了一个良好的持续交付状态?为了找到这个问题的答案,GoCD团队采访了很多专家、程序员、运维人员,以及在DevOps链条各节点上的小伙伴。同时他们也采访了业务干系人,因为成功的持续交付能够让技术更好地服务于业务、推进业务收益,进而可以让实现持续集成的潜在工作也被认可有其价值。 通过综合分析总结,我们识别了4个有价值的度量指标:
  • 可发布的软件包数量
  • 周期时间
  • 故障平均间隔时间
  • 故障平均恢复时间

你有多少可发布的软件包?

为了实现成功的持续交付,你需要持续提交代码,特别是持续提交代码到主干分支(master)。如果总是向个人分支提交代码,那么这样的提交将不会对即将发布生产的代码带来任何价值。 保持较高的可发布包的交付频率,同时依赖于团队已对软件包完成了可信赖的测试。一个我们常见的反面模式就是持续数小时、甚至一整天的测试验证活动。在很多场景下,这些测试是不可信赖,也就意味着当测试结束的时候,你未必比测试初期对交付质量更有信心。这让事情变得成本很高,因为它使每个人对发布都极其小心谨慎。部署软件看上去就像是俄罗斯轮盘赌游戏一样。 这个指标也强调产品团队和研发工程团队协作的重要性。跨职能团队必须能够建立一个路线图,使得用户故事能以足够小的粒度去拆分,使得团队可以细粒度的发布故事,真正给用户交付价值。如果产品团队并不配合这种协作模式,那么研发团队则只能一次性开发交付较大规模的功能,也许直到游戏的最后一分钟,大家才知道这个大功能并没有带来任何价值。 作为严谨的路线图规划的一个补充,研发团队应该利用一些新的技术,如feature toggles(特性切换),通过feature toggles配置实现功能的打开或者关闭(控制展示与否),从而实现把Feature发布到生产环境,同时保持客户的无感知状态(如蓝绿发布等场景)。

你的周期时间是多少?

我们从开发人员口中最常听到的痛点是周期太长,这个周期从提交代码开始,经过测试、验证到部署,对开发人员来讲这是一个漫长而焦躁的过程。因为在代码提交等待反馈的过程中,他们经常要被迫中断性的切换工作思路,也是一种时间的浪费。XKCD的关于击剑等待代码编译的漫画,就轻松而又非常真实的反映了这个过程。 ​ 这段停滞时间不但不能让你加速交付价值给客户,还会造成工作焦点发散。提高团队的周期依赖于高效的测试和快速的反馈闭环。 下面有一些实践可以帮助你缩短周期:
  1. 尽早执行UT,让UT早于Pipeline和复杂的、需要长时间执行的自动测试,这将会让你提前获得一些基本反馈,节约时间。
  2. 让依赖在Pineline stage间传递可以避免不必要的重复构建,这会比较有帮助。
  3. 让构建尽可能的并行执行,这也会节约不少时间。
  4. 最后,确保你拿到了正确的构建资源,这样不管你需要跑什么构建,都会有充足的Agent去跑各类任务。

你的故障平均间隔时间和平均恢复时间是多少?

故障平均间隔时间和恢复时间往往是相关联的,因为二者间的平衡非常重要。故障平均间隔时间让团队总是尽可能的确保版本的稳定,尽力避免失败。但是,仅仅关注平均失败间隔时间、减少失败,会导致团队过度谨慎,不愿发布新版本。而软件研发的核心是不断提供新价值给用户,满足用户需求。因此,平均故障恢复时间将会是一个关键制衡点,该指标展示团队纠正错误的能力。 达到理想的平均故障间隔时间,依赖于更早的反馈闭环,以及在测试环境中的缜密验证。这类验证应该在数据和环境与生产完全一样的测试环境中执行。强大的本地构建能力也是必须的,因为失败是在所难免的,因此尽可能缩短故障恢复时间就变得尤为重要。当遇到一个Pipeline失败或者发布失败,你需要多久可以回滚到一个稳定的版本上?对生产环境的持续稳定监控是一项基本能力。团队应该从监控和报警中获知故障发生,而不应该在客户投诉抱怨时才获知故障。 故障恢复演练,如回滚,可以缩短平均恢复时间。建立一套自动回滚机制,可以让团队节约出时间去深入分析问题根因。快速分析定位问题依赖于信息化的日志系统,通过获取有价值的日志信息,开发人员可以准确定位一个发生在凌晨2点的故障。

总结

回到彼得.德鲁克大师的名言,为了改进某些事务,我们首先需要找方法去度量它,让它可视化。这也就是为什么要建立数据仪表盘、让度量可视化的价值,这可以让团队更有责任和关联意识。另一方面,我也不想说度量是万金油。一定存着一些无意义的度量和虚荣的指标。最终,你希望的是激励员工去关注棘手问题,通过解决这些问题,让员工给团队和组织创造价值。 作者:Alison Polton-Simon
原文链接:https://www.gocd.org/2018/01/31/continuous-delivery-metrics/
译者:青铜译者-车晓雪 (Hebe Che)
审校:白银译者-胡帅
Category持续交付

©2022 中国DevOps社区版权所有;本站内容许可 CC 4.0

关注社区: