如何塑造团队持续交付的文化——暨高可用架构持续交付研讨会

持续交付是目前的一个挺火的概念，它所描述的软件开发，是从原始需求识别到 最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺 畅流动，能够以较短地周期完成需求的小粒度频繁交付。...



导读：持续交付是目前的一个挺火的概念，它所描述的软件开发，是从原始需求识别到 最终产品部署到生产环境这个流程中，需求以小批量形式在团队的各个角色间顺 畅流动，能够以较短地周期完成需求的小粒度频繁交付。本文作者对如何开始持续交付表达了自己的看法。

持续交付是当今软件研发领域的一个热点，但往往看起来这是一个不可能完成的任务。 “我们的系统怎么能做到？” 在遗留系统上工作的开发人员会反问。 虽然有各种技术障碍要克服，但实践持续交付可能更多需要有重大的团队文化变革。 在这篇文章中，我将描述我们在客户中使用的一些关键实践和流程，以塑造成一个有持续交付文化的团队。

理解团队现有流程

计算机从不自己行动，在 SkyNet 或其他 AI 革命到来前，计算机还将继续按照程序行事。因此，程序员需要理解所涉及的每个步骤。

因此，为了自动化交付流程，其中所有步骤必须是完全已知的。不幸的是，大多数开发人员对交付流程仅有一个大致的了解，只有少数人真正了解所有的细节情况。在白板上列举出所有步骤，包括从开发人员机器上获取本地分支代码开始，到生产环境运行的每一步，确保每个人都能全面了解当前的环境是如何部署软件的。

这个练习可以暴露令人惊讶的细节，也会发现很多之前认为理所当然的流程实际是多么的低效。这是一件好事！更多地了解他人工作的复杂性，建立了同理心，识别组织的弱点，使团队保持谦卑。在笔者的团队，我们非常重视这些性格 - 它是我们这些码农走向成功的关键因素。

此外，定义现有的交付流程也是对耐心的测试。实现持续交付的道路可能漫长而艰巨，但是建立一个基线，以便对未来的改进进行比较，这有助于每个人在开发渐进改进的同时，看到流程的逐步改进。

定义“完成”

确定任务完成的时间可能非常困难，是在工程师 Pull Request 开始之后？review 之后？ QA 测试过后？合并代码以后？上线发布后？五个不同的人可以提供这五个不同的答案。不同的团队对这个问题有不同的理解是正常的，但是在同一团队中，不同角色的人常常对此也有不一致的观点。

像上面的交付流程一样，任务完成的定义可以被明确地形式化。在这个特定的情况，我的团队的“完成”标准包括三个部分（除了通过测试，当然）：

• 两个没在这个工作上的开发人员 review 并批准了 pull request。
• 质量保证工程师已在仿真服务器上测试该功能。
• 产品负责人已在仿真服务器上的功能进测试。

这是一个非常严格的“完成”的定义。在一些组织中，产品负责人的时间是非常宝贵的，对于交付流程，他们不太愿意有大量的日常的参与。然而，正如“软件工艺宣言”所述，我们重视与客户的高效合作伙伴关系。增加人们的责任和问责制不但给开发人员，也给每个人带来好处。例如，QA 可以更好地管理其工作负载，并且可以在更稳定的步伐下自动化回归测试。同时，产品负责人早期就介入，使得更少的需求因为误工被保留到下一次迭代。

软件工艺宣言

http://manifesto.softwarecraftsmanship.org/#/zh-cn

对于开发人员，“完成”的清晰并且彻底的定义，可以减少交付流程中的不透明度。开发人员可以自由地合并自己的 pull request，而不是在发布之前来做，也不会被同事阻止合并，或者告知只接收指定功能，或者需要指定日期来合并代码。这不仅减少合并长期分支导致的合并冲突，同时也改善士气。也许很幸运，我没有与任何不关心实际生产环境的开发人员共事。在我们的客户那，开发人员认可合并代码是他们的工作责任，而不是说“功能已经开发完成，只是等待下个版本合并到 master”。此外，随着问责制的全面加强，当 QA 或产品经理落后于他们的进度时，开发人员更容易引用这些约定来对特定的延迟问责。

确定发布节奏

人类是习惯的生物，日程帮助我们管理时间，优先处理我们的工作，并保持生产力。奥巴马总统只穿灰色或蓝色西装，减少了他必须做的每日决定的数量，帮助他保持精神上的锋利。类似地，遵循一致的部署计划将部署变为普通工作日的简单部分。

许多人认为持续交付意味着在每次提交代码时推送到 master 分支并部署，但实际上这是有问题的。 Martin Fowler 将持续交付定义为

“软件开发学科，您可以以这样的方式构建软件，以便软件可以随时发布到生产中”;

Jez Humble 将其描述为

“以可持续的方式，安全，快速地将所有类型的变化转变为生产或用户手中的能力”。

这些定义都没有指定任何实现细节，例如“在每次合并发布到主干上”，这当然是一种选择方式，但不是唯一的方式。

另外一种可持续的选择是，定期向生产环境发布代码。只需选择常规计划进行部署，并遵守该计划。我们的客户决定每天早上 10:30 进行新版上线。该决定消除了关于何时将发生下一次部署的所有模糊性；结合我们的“完成”标准以及与质量保证和产品团队的密切合作，我们的团队可以对何时推送某些功能做出更好的预测。此外，频繁且有计划的部署足以减少很多为准备部署而进行的工作 - 如果明天还有另一次部署，每个人都可以花时间做好他们的工作。

自动化

当然，还有许多步骤可以达到超高效的部署。 本文中没有任何内容讨论自动化进程中的任何步骤 - 从合并 pull request 到打开线上负载均衡上的开关等操作仍然在此时手动执行。 然而，剩下的只是技术问题（有太多可能的实现）。 从这里开始，建立一种重视同理心，谦卑，问责和日常工作的文化，这将在给我们在将来解决各种技术问题时带来巨大的红利。

本文由高可用架构志愿者翻译，原文地址

https://8thlight.com/blog/mike-knepper/2016/11/10/moving-towards-continuous-delivery.html

持续交付线下研讨活动预告

为了更好的探讨如何建立一种重视同理心，谦卑，问责和日常工作的文化，在团队中成功的建立持续交付流程，并且具备完善的工具体系，高可用架构特 11.19 在北京组织持续交付线下闭门研讨，了解业界包括新浪、百度、腾讯、熊猫TV、雪球、知乎等团队优秀的实践经验。


点击阅读原文了解 GIAC 完整日程。

    关注 高可用架构