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

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

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

理解团队现有流程

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

定义“完成”

    

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

• 两个没在这个工作上的开发人员 review 并批准了 pull request。

• 质量保证工程师已在仿真服务器上测试该功能。

• 产品负责人已在仿真服务器上的功能进测试。

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

软件工艺宣言

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

确定发布节奏

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

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

Jez Humble 将其描述为

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

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

自动化

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

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

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

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

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

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