持续交付的经济性

本文最初发布于https://blog.squadlytics.com/the-economy-of-continuous-delivery

关于持续交付 (CD) 的讨论大多集中在技术层面。这很正常！从手动、高风险的发布方式过渡到每天多次将代码部署到生产环境，需要考虑很多方面。你需要采用自动化测试，确保足够的代码覆盖率，并考虑数据迁移、基础设施即代码 (IaC) 和 API 版本控制。你还会讨论分支策略、功能开关的实现以及微服务的使用。此外，你还会考虑监控工具和回滚方案。采用持续交付需要切实可行的策略和规划。

但这样做的问题在于，它常常会让人觉得这是一项以开发人员为中心的举措，似乎只对工程团队有利。毕竟，改进部署流程所花费的时间，就意味着无法用于为客户开发新功能。正因如此，很难说服利益相关者相信这项工作的价值所在。

这是一个框架问题。持续交付并非旨在让开发者更快乐，尽管这确实是其重要的副产品。持续交付的首要目标是超越竞争对手，并让客户满意。

是什么让你具有竞争力？

要理解为什么客户洞察对任何企业都至关重要，我们需要回归基本原则。你很少能仅仅因为是第一个进入市场的参与者就赢得市场，尤其是在如今科技大幅降低客户转换成本的时代。你之所以能赢，是因为你比任何人都更了解人们的需求。归根结底，就是拥有比同行更多的信息和知识，并能够利用这些信息打造出色的产品。

这就是敏捷开发和精益创业方法如此成功的原因之一。它们使团队能够快速地在市场上测试想法并获得用户反馈。你可以在几周内调整方向，而无需等待数月才能知道你的假设是否正确。

所以问题是，如何减少摩擦，更快地从市场获取数据？

实践中的迭代

产品开发中常见的矛盾源于市场团队和工程团队的运作速度差异。当有新功能的想法时，市场团队通常能在几天内制定营销方案并准备好预算，而开发团队可能需要几周甚至几个月的时间才能将功能推向市场。这种因急于尽快将功能推向市场而产生的挫败感是可以理解的。

但现在，你的功能已经上线。几天后，你收到了客户的反馈，并找到了一个可以提升转化率的小技巧。但你的团队只能再等两周才能发布——不是因为开发本身有多复杂，而是因为部署成本高昂且风险很大。

所以，你推出了一项新功能，也从市场获得了宝贵的信息，但却无法将其转化为实际行动。这正在让你白白损失金钱，因为你的营销预算被浪费在了转化率远低于预期的功能上。你知道，每过一天，你就在流失客户。

快速发布周期是为了保持竞争力。

我们必须摒弃将部署挑战视为技术问题、开发人员可有可无的附加功能这种观念。它实际上是一个必须解决的业务难题，才能保持竞争力。每次发布都是与客户交流、测试想法并加以改进的机会。能够每周多次交付的团队，才能帮助其所在组织快速响应市场需求。

然后，你会看到平稳的发布周期带来的绝佳副作用：你的团队会明显更快乐，因为他们的压力会更小，并且能够更频繁地看到他们的工作是如何帮助人们的。

Squadlytics 帮助团队衡量和优化发布周期。立即免费试用 Squadlytics。

（图片来自Unsplash用户Pope Moysuh ）