我为什么要写这个？前几天，我听到W.Edwards戴明（W.Edwards-Deming）的一句非常真实的话："没有数据，你只是另一个有意见的人"，这让我想起了衡量质量有多么困难，但同时也很重要。但让我们先退一步，问问自己，为什么我们要跟踪指标？指标帮助我们：明白我们是不是越来越好了，一个又一个版本理解客户所遭受的痛苦推动我们的路线图，以强化客户最痛苦的领域了解质量活动对我们可交付成果的影响韵律学本着这种精神，我整理了一组CloudBees-Jenkins企业指标来跟踪：影响客户的bug，每个版本，每个组件：这实际上是问题升级的支持影响客户，需要紧急修复。我们目前的主要目标是把这些减少到零。内部报告的每个发布行的bug：这个度量捕获了在开发、测试和dogfooding过程中，在它们影响客户之前我们在内部捕获了多少个问题。专业服务团队报告的每个发布线的bug：从1.6.0开始，专业服务团队就与客户进行安装。这意味着客户不太可能报告安装问题，而是由PS团队来报告。我们决定跟踪此问题，以确保我们没有掩盖安装/CLI问题，这些问题可能会随着时间的推移而变得更糟（最终，它会直接影响客户）。过程和时间段我回到了2016年11月发布的1.5.0，并开始确保所有问题在JIRA中都有正确的受影响版本，并分配了正确的组件，直到最新版本1.7.0。这样我们就可以比较梨和梨，苹果和苹果。结果：您可以找到下面的图表，显示了从1.5.0到1.7.0版本的演变。我们将比较1.5.x和1.6.x。作为总结：我们已经从6个安装问题减少到1个，并从4个升级问题减少到0个。升级对客户来说不再可怕了。与1.5.x版本相比，我们在1.6.x版本中遇到的客户问题不到50%，从20个升级到9个升级问题。这是一个重大的成就，因为1.6.x版本中解决的问题数量是1.5.x版本的两倍。ElasticSearch是下一个热门话题，有三个问题影响到客户。这是我们的重点领域。我们是怎么做到的在CloudBees-Jenkins Enterprise发布之前，很明显最大的客户问题是安装过程和升级。因此，我们决定集中精力强化这两个方面。怎么用？自动化审计-了解我们是如何持续测试升级和安装的，丢失的案例以及自动化这些的计划。在这项工作之后，所有的升级方案都被覆盖了。安装测试-我们执行了几个bug bash，这是一个集合测试会话，覆盖所有支持平台中的安装。自动化在这方面也得到了改进。发布测试——在为发布定义了p1cloudbees-Jenkins企业案例之后，当这些案例变得自动化时，我们一直在以手动/自动化的方式测试它们的发布版本。CloudBees Jenkins Enterprise在公开发布之前的内部dogfooding—在向客户发布软件之前，我们先在内部使用软件，这样我们就可以体验真正的使用体验—并防止问题影响到我们的客户。发布阻止和升级问题分析-对于每个版本，我们分析阻止发布的问题以及客户升级的问题，以确保我们在待办事项中有行动，以防止将来发生这些问题。这样我们就结束了失败、修复、分析、提出预防措施和从错误中吸取教训的循环。然后我们将这些新知识融入我们的日常发展中然后呢？持续改进现在，ElasticSearch已经成为热门话题，我们正致力于更好地了解问题所在，并制定一个质量改进计划，以强化该领域的测试。到目前为止，我们对ES病例进行了全面回归分析，发现了一些问题。我们开始在监控方面进行一些投资，以更好地了解ES大小和崩溃情况。但在这些指标中，我们总是忽略了所有客户摩擦的情况，有解决问题的方法、修补程序或重新启动，但它从未升级到工程。为了在这方面有可见性，工程和支持团队正在合作，开始在Zendesk中报告这些，这样我们就可以有另一个图表来告诉我们真正的支持故事。请继续关注数据分析！伊莎贝尔·维拉迪斯质量保证经理云蜂 了解更多想了解詹金斯的最新情况吗？订阅詹金斯通讯，连续信息。这个月刊包含了詹金斯社区所有最新的有趣和有用的事件，直接发送到你的收件箱。