Pipedrive如何在每天部署50+次的情况下支持质量发布？

“我把每一天都看作是比昨天高出一个档次的机会——无论是在服务质量、交付、速度还是业务的其它任何方面。”

— Daniel Snyder

介绍 — 速度 Vs. 质量

客户总是在寻找有效的解决方案，来满足他们已经确定地需求，并为他们节省资金。在企业致力于生产高效、节省成本的东西时，他们也希望自己的产品被认为是高质量的——Pipedrive 也不例外。当你开发一个产品，不仅提供一流的功能，还经得起时间的考验，然后你就拥有了一款客户满意且自己感到自豪的产品。

然而，我们不应该忽视另外一个指标的价值（它也会影响质量）——交付速度。关注交付速度是为了确保竞争优势。平均上，Pipedrive 每周向生产环境进行大约 500 次部署，拥有超过 250 名开发人员，没有专门的测试部门。

问题是，速度是以质量为代价的。此外，保持平衡也需要一些努力。我们十年来是如何保持速度和质量的呢？在深入讨论这个问题之前，我们先来讨论下我们在 Pipedrive 遵循的流程。

Pipedrive 的“幕后”流程

为了弥补不同团队同步工作之间的沟通差距，我们在软件开发过程中遵循 DevOps 原则。这额外促进了实现更快的交付和反馈。

为了在不妨碍团队发布流程的同时采用 DevOps 流程，我们几乎不需要专门的测试专家。在我们以开发人员为中心的环境中，开发人员负责测试和部署他们的变更。我们通过依赖专注于测试自动化的持续测试（Continuous Testing）来弥补差距。

我们没有提供一个安全网来捕获失败，而是帮助团队适应失败。为此，我们引入了几个专业团队，例如 DevOps、SRE、QA 分析师、支持工程师、基础设施工程师、敏捷/个人教练等，他们支持所有的开发小组：围绕特定产品领域的产品开发单元。

例如，站点可靠性工程（Site Reliability Engineering，SRE）团队专注于与产品和开发团队协作来创建可伸缩的架构，同时提高我们服务的性能、稳定性和可靠性。

既然你们对于 Pipedrive 的运作流程已经有了比较好的理解，我们将进一步讨论我们是如何保证快速交付和内在品质的。

我们如何保持交付速度

一个完全自动化的发布流程

平均上，我们每周自动测试和执行多达 500 次部署（你可以在“Fueling the Rocket for 500 deploys per week”这一文章中了解更多关于我们如何实现这一点的信息）。

功能标记/切换

在我们的持续交付系统，我们希望将新功能作为我们日常发布的一部分。如果功能还需要一些时间来完成，代码在这些日常发布期间被一个功能标记禁用。这使得我们可以增量地将代码推送到生产环境，每次发布都非常小且易于管理。

任务框架

我们采用了我们自己的 Pipedrive 敏捷框架，开发部门专注于产品领域，与工程小组一起协作。使用这些小组的一个好处是，他们专注于特定时间的某一特定功能，最终提供更快的结果。（你可以在“Scaling Pipedrive Engineering — From Teams to Tribes”这一文章中了解更多关于这个框架的信息。）

我们如何保持软件质量

在 DevOps 中保证质量仍然是一个令人生畏的难题，你需要投入更多精力来平衡质量。

下面是一些可行的方法：

可控的发布

为了逐步推进并控制新功能的持续交付，我们使用了（上文提到的）功能标记。我们采用了分阶段的方法，这样只有一部分用户可以访问这个功能。如果我们的支持票和监控显示最初的发布是成功的，我们会逐步增加到 100%的用户都有这个功能。通过这种可控的方法，我们确保以最小的风险向客户引入新功能。

测试自动化

我们依赖专注于测试自动化的持续测试。测试自动化使我们能够快速高效地进行测试，并且参与的员工更少。测试自动化发生在一个 CI/CD 流程中，向团队提供快速的反馈，这反回来又支持了频繁发布。

可操作的数据

我们使用与客户满意度直接相关的可靠指标。我们还收集客户反馈来了解更多关于客户体验的信息，并跟踪客户 NPS 的变化，将其作为客户满意度当前状态和潜在流失风险的一个指标。

除了测量 Pipedrive 如何被使用之外，我们还测量我们的项目运行效率、任务/启动板运行方式以及 bugs 的已创建 vs.已解决的数量，等等——必要时采取行动。

Grafana 的 DevOps 指标仪表板

最后，我们还跟踪质量相关的指标。目前，我们主要的质量指标如下：

• 产品稳定性——向客户表明产品整体的总体稳定性。*这个数据受事件数和持续时间影响。

• 严重事件——数量、持续时间和受这些事件影响的功能

• 生产环境引入的bugs——这些bugs的总数以及这些bugs打破他们的SLA的数量

• 支持工程中的新报告案例——客户报告的关于他们所遇到的问题的案例。

重要的是，对于我们收集到的指标，趋势是可见的和可观测的——为我们指明了特定领域发展的方向，这使得数据驱动的软件质量决策成为可能。这些指标在 Tableau 收集，然后每周共享到一个专用频道。

在 Tableau 中我们的质量关键指标的主面板

所有这些指标都是在组织中获得认可并为质量问题带来可信度的关键部分。

利益相关者一致

我们广泛使用可操作的数据。例如，每周向利益相关者（例如工程经理）提供工程运营指标。这提高了可见性并在整个组织实现了数据驱动的质量决策。

QA 分析师

我们采用 QA 分析师的角色来支持产品组织和各种工作小组来确保应用程序在最重要的领域得到足够的测试，识别自动测试的机会，并通过在需要时组织 bug 脚本会话来支持手动测试需求，等等。他们的重点是全组织的质量相关倡议、度量可视化、分析和任务规划。

QA 大使

还有一个专门的轮换角色，把更多的注意力集中在日常开发过程中的软件质量上。这个角色专注于提高人们对质量的认识和兴趣，推动质量相关的倡议，并帮助在各个工作小组内做出更好的质量相关的决策。

对延期零容忍

QA 分析师和大使为客户辩护，帮助避免拖延质量问题。有时候，由于上市时间的压力而超出你的控制范围，但是只要有可能，他们都会鼓励团队立即修复问题，以免问题一直累积。

内部测试

对于一些重要的领域，我们的员工可能被要求使用我们制作的软件的预发布版本来发现问题并提供反馈。

“完成”的定义

在我们的发布/预着陆检查清单中，我们有一套定义“完成”的标准。我们创建了这种检查清单以及任务/项目文档，提醒我们在发布期间应该做什么，来满足一定的技术成熟度。

预着陆/发布清单摘录

为了从模板中创建一个合适的检查清单，我们将[从模板宏创建]添加到一个创建子任务的任务页面。

倡导质量的明确政策和协议

为了达到和维持所需的流程和软件质量，需要遵循特定的政策和指南。

这种协议的一个例子是，生产缺陷管理流程。它的目的是识别影响生产环境的 bugs 并对其进行优先级排序，使它们与 ETA 保持一致，以确保这些 bugs 被及时处理，从而最小化对业务的影响。

重要的是要记住，即使是不严重的问题也会对客户的质量感知产生复杂的负面影响并降低产品的可用性。

结论

那么怎样才能在速度和质量之间取得平衡呢？没有简单的答案或神奇的方案，但你可以从我们正在努力创建的东西和我们尚未完善的东西中获得一些灵感：

在生产中测试

在生产中测试是实现速度/质量平衡的方法之一。通过提前发布软件并采用允许用户测试的实践，一旦软件投入运行，开发部门就可以缓解风险。决策可以由实际用户与生产软件的交互数据来驱动。

DevOps

另一个直接的方案是采用 DevOps 和 SRE，而且通过减少上市时间并带来更多透明度和稳定性，它帮助我们以更好的方式与公司合作。

质量文化

质量文化非常重要！根据《哈佛商业评论》（Harvard Business Review），拥有强烈的质量文化的公司所遇到的错误比没有质量文化的公司少一半。这会转变成真正的商业价值：提高你的质量文化能节省一大笔钱，并带来更高的用户满意度。

对问题的信心

综上所述，一个人需要良好的常识。如果你已经验证了问题并证明它对客户非常重要，那么你就不应该走任何捷径——而是应该尽可能以最佳质量实现解决方案。

下一步行动

不仅如此，我们还将引入新的 mini-live 或基于区域的 canary 部署，这些将被用来在新的部署被传播到更广的客户群之前对这些部署进行验证。我们还开始着手创建质量和测试相关的培训。接下来还有很多事情，但这会在以后的另一篇文章中讨论。

作者介绍

Valeriia Iuzhakova是 Pipedrive 的一名首席 QA 分析师。

原文链接

How Pipedrive Supports Quality Releases while Deploying 50+ Times Per Day