走向持续交付

2017-04-14   出处: 8thligh  作/译者:mike knepper

                                                  

持续交付是当今软件行业的一个热门概念,但它往往似乎是一个不可能的目标。 “我们的系统怎么能做到这一点”。在克服几个常见的技术障碍的同时,实践持续交付可能也需要重大的文化变革。在这篇文章中,我将介绍一些我们一个客户使用的关键经历和过程来展现持续交付文化。

了解当前过程

计算机的事情是不会犯错的, 在下一场网络革命到来之前,计算机将继续做他们被编程做的事情  不多做,也不少做。 因此,程序员需要明确,无论是自动排序算法还是全局业务,所涉及的每个步骤都必须被确认和编程。

因此,为了自动化部署过程,该过程的步骤必须是完全已知的。 不幸的是,大多数开发人员对部署过程只是有一个大致的了解,只有少数人真正了解所有的细节和边缘情况。 写出代码如何从开发人员机器上的本地分支到生产中运行的每一步, 确保了每个人都能全面了解他们今天如何运送软件。

这个练习可以暴露过程中一些令人惊讶的细节和大多数都认为理所当然的低效率。 这是一件好事! 更多地了解他人工作的复杂性可以建立同理心,并可以确定组织中的弱点使团队谦卑。 8th Light,我们强烈评价这些特性 它们是助我们成功的软件工具。

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


定义“完成”

确定故事完成的时间可能会非常困难。 是否在拉取请求已打开时?开发人员审核? QA? 合并? 部署? 五个不同的人会提供这五个不同的答案。 虽然不同的团队有不同的要求是合理的,但经常是同一团队中但是具有不同角色的人会有不一致的观点。

像上面的部署过程一样,要被考虑完成的故事的要求可以被明确地形式化。 在这个特定的客户端,我的团队的“完成”标准包括三个部分(当然除了通过测试):

两个没有在故事上工作的开发人员审核并批准了拉取请求。

QA已在服务器上测试该功能。

产品利益相关者已与服务器上的功能进行了交互。

这是一个非常严格的“完成”的定义,并问了很多不同的人。 在一些组织中,利益相关者的时间是非常重要的,他们可能不愿意这么大量的日常工作。 然而,正如“软件工艺宣言”所述,我们重视与客户的高效合作伙伴关系。 增加每个人的责任,而不仅仅是开发者,会给每个人带来好处。 例如,QA可以更好地管理他们的工作量,并可以更自动化的回归测试更迭代地给予一个更稳定的步伐。 同时,产品所有者喜欢在演示中看到更少的意外,以及由于太晚,意外的反馈导致更少的故事被保留到下一个迭代。

对于开发人员,清晰明确的定义“完成”为在部署过程中那些不透明的步骤提供了宝贵的透明度。开发人员可以自由地合并自己的pull请求,而不是被同事制约,被动的选择什么和什么时候发布。这不仅规避了较少的长时间运行的分支导致合并冲突,进而提高了生产力,而且还提高了团队士气。也许我很幸运,我没有与任何不在乎实际运输软件到生产的开发人员合作。在我们的客户端,开发人员接受了合并工作的责任,很高兴不再在立场上报告他们的请求是“准备好了,只是等待释放以合并为主”。此外,随着问责制的全面加强,当QA或产品所有者落后于他们的责任时,开发人员更容易引用这些当事方对特定延迟负责。


建立节奏

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

许多人认为持续交付意味着每次推送到主分支时自动生产部署,但实际上这不是等价的。 Martin Fowler将“持续交付”定义为“软件开发学科,您可以以这样的方式构建软件,以便软件可以随时发布到生产中”; Jez Humble将其描述为“以可持续的方式安全,快速地将所有类型的变化转变为生产或用户手中的能力”。 这些定义都没有指定任何实现细节,例如“每次合并到主机上”,这当然是一种方式,但不是唯一的方式。

定期向生产部门发布代码的另一种可持续方法是部署节奏。 只需选择一个常规计划进行部署,并坚持该计划。 我们的客户决定在每天早上10:30进行部署。 此决定规避了关于何时发生下一次部署的所有模糊性; 结合我们的“完成”标准以及与QA和产品团队的密切合作,我们的团队可以对何时发送某些故事做出更好的预测。 此外,经常调度部署频繁,减少了急于执行或审查的诱惑,以便进行部署 - 如果明天会有另一个,每个人都可以花时间做好他们的工作。


自动化

当然,还有许多步骤可以达到超高效的部署管道。此帖子中没有任何内容在实际当中会自动完成此过程中的任何步骤,现如今,从合并pull请求到负载平衡器上的翻转开关的一切仍然需要手动执行。 然而,剩下的只是技术问题(这个帖子有太多可能的实现)。 这里概述的步骤,开始建立一种重视同理心,谦卑,问责和日常工作的文化,将在解决这些技术问题和未来其他技术问题时有所帮助。



【英文原文:https://8thlight.com/blog/mike-knepper/2016/11/10/moving-towards-continuous-delivery.html】


{测试窝原创译文,译者:周婷婷}

译者简介:周婷婷,专注于云计算、自动化、网络运维领域的工作者。



声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
295° /2952 人阅读/0 条评论 发表评论

登录 后发表评论
最新文章