BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

避免热修复部署的方法

| 作者 Adam Pahlevi 关注 0 他的粉丝 ,译者 张卫滨 关注 13 他的粉丝 发布于 2016年6月14日. 估计阅读时间: 21 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

我们,包括我的团队以及我本人,都很恐惧重新部署!设想一下吧,我们不是在做一项新特性,而是必须要重新部署系统:版本管理、要求scrum master编写变更请求、对系统进行打包、跑到IT运维团队那里,请求他们帮着进行部署。到一天结束的时候,会发现燃尽图进度不理想,所有的利益相关方都会感到不爽。

作为一名软件工程师,非常不幸的一件事情在于软件是看不见摸不着的。它的这一特点,使得我们很难看到它所具有的漏洞。当在生产环境发现这些漏洞的时候,如果对其打补丁或进行热修复的话,将会导致费时费力的重部署。本文将会展示一些拿来即用的技巧,这些技巧能够帮助我们减少热修复部署的需要。

但是Bug无处不在

在作为软件工程师的职业生涯中,我看到过各种类型的错误,或者工程师所谓的“bug”。它们其实无处不在:在服务器端、在客户端、在浏览器上、在网络设备中!

Bug不仅无处不在,它们还会带来一定的成本。发现它们、评估它们的影响以及对其进行修正(也就是调试的过程)都是成本高昂的。NASA曾经经历过史上成本最高的bug之一,1.25亿美元消散在了火星稀薄的空气之中。

但是,“人都会犯错的”,NASA项目的JPL主管Tom Gavin曾经这样说道。不幸的是,软件工程的本质特点让我们很难在开发的早期就探测到潜在的bug。

我们可以采取一些措施,降低不必要的bug侵入到软件中的可能性。这能最小化热修复部署的风险。本文在三个方面讨论了这些措施:

  1. 开发期
  2. 部署之前
  3. 部署之后

开发期

从一个清晰的Story开始

一个好的Story对于什么是完成有着良好的定义,并且可以进行拆分。好的Story会在以下方面给团队带来帮助:

  1. 减少歧义性;
  2. 帮助团队理解Story的目的;
  3. 让开发过程更加快速;
  4. 支持更高质量的交付。

好的Story首先要有一个好的标题,通常格式如下:

作为一个[角色],我想要[活动],以便于实现[目标/价值]

接下来,它需要有一个完成状态的良好定义。完成状态的定义能够告诉工程团队每个可测试的场景,在这个Story可交付之前,必须要包含这些场景。完成状态的定义是由product owner编写的,并且会由其进行检查。

工程团队需要将任务进行拆分。列表中要包含构建该Story的技术步骤。需要注意的是,每一项任务应该在一天之内完成,这是一项任务完成时间的上限——如果做不到的话,那就要进行进一步地拆分。这样的话,product owner能够更容易地跟踪进度,也能让团队感到有一种成就感。

而定义较差的Story一般会具有下面的特点:

  1. 不清晰,Story的目标是什么?
  2. 缺少总体的样例。甚至连包含预期输出的简单样例都没有。
  3. 完成的定义模棱两可,不知道预期结果是什么。

例如,有一个Story是要对系统A进行变更的,但是没有提及这个变更会对同一团队维护的系统B产生影响。因此,就会出现bug!但是,如果系统B是由其他的团队来维护的话,又该如何防止这种问题的出现的呢?我们稍后将会对其进行进一步的讨论。

不要匆忙了事的文化

这是除了Story定义之外,最重要的事情。我首先给你讲述一下我们的经历,我们是如何通过不那么急切行事,避免热修复部署的。

以前,我们在进行部署的时候,都会弥漫着一种紧迫感。其实就是在部署的那一天,希望包含尽可能多的Story,我们为此感到了很大的压力。这样的结果就是对细节失去关注,我们经常需要重新部署。有时候,我们不得不部署三次来进行热修复,这真的让人非常尴尬。

但是,当我们开始按照稳健的节奏工作时,就发现很少再需要热修复部署了,当然偶尔会发生的安全缺陷除外。我们非常冷静地进行判断:如果某个Story无法进行全面充分的测试,那么在部署时就不会包含该Story,我们会等待下一个周期。我们非常坚定地执行这个规则,因此很少需要重新部署。

最好是一次部署成功,而不是匆忙进行部署,却要失败好多次。

这里的关键在于分配优先级,那是怎么做的呢?

要事优先。不要让客户、商业方案、负责客服的家伙或者其他人告诉你“这个特性必须要立刻加到生产版本中”。对于这种情况,要想办法对他们说不。很可能出现的情况是,即便你交付了这个特性,它在几个月内也完全用不着。

但是,有些特性、修复以及缺陷确实需要快速响应,关键就是确定优先级!我们通常有四个层级的优先级:P0、P1、P2和P3。

如果有紧急的Story,并且需要快速部署的话,那为其分配的优先级就是P1。例如,如果修改了登录页的代码之后,潜在用户无法进行注册了,那么就要将这个bug考虑作为P1级别。

比P1更高的是P0。P0是非常、非常严重的问题。它可能会导致整个系统完全无法使用,可能会导致很多客户暴跳如雷,可能会让你的公司破产。如果这个问题需要你立即从床上跳起来去解决,那它就是我所说的这种类型。

P0级别bug的一个样例就是系统在部署之后,所消耗的内存空间呈指数级增长,导致性能的下降,所有的用户均无法可靠地访问系统。这需要“紧急集合(all hands on deck)”式的响应,快速修正问题(但是不要恐慌)并尽可能快速地部署热修复版本。

P2是针对当前sprint的,在sprint开始之前,所有P2的Story都经过了慎重地考虑,按照规划,它们需要包含在当前sprint之中。

比P2级别更低的是P3,它能够等到规划未来sprint时再进行考虑。我们该怎样判断某个Story是P3呢?如果不部署所要求Story,有其他方式也能达到预期输出的话,那么这个Story就可以进行等待。P3是默认的优先级。对于未规划的所有特性/bug修正的请求,都将其优先级定为P3。

遵循上述的指导,我们有了更好的精神状态,在团队所编写的代码中,bug也会更少。

好的编码实践

如果你有一个团队的话,要进行结对编程,至少偶尔要这样做。结对编程有利于知识的共享,新雇员要与团队中经验丰富的编码人员结对。通过这种方式,新雇员能够快速学习到系统中的知识,并且能够开始独立实现特性。有些公司则更进一步,将结对编程变成了常态,为两位开发人员只提供一台计算机,强迫他们进行结对编程。

编写良好的文档良好的提交信息。有很多其他的技术能够指导我们编写更好的代码:不要硬编码值、使用整洁命名的变量,使代码易于阅读等等。寻找好的编码参考实践,并确保整个团队理解为什么使用它们以及如何使用它们。

还要考虑到物理因素。允许每个人按照其最高效的方式工作——如果有人觉得他们在晚上工作状态更好的话,那就让他们晚上工作。要照顾到人的各个方面——好的物理环境、具有安全感的工作文化以及健康的习惯,如保证好的夜晚睡眠质量,这些会让人压力更小,精力更充沛,有利于产生更好的产品。

质量控制

质量控制中最重要的一个方面就是测试。测试分为很多种:集成测试、单元测试、黑盒、白盒以及用户验收测试(user acceptance testing,UAT)。在测试方面,应该是没有谈判余地的。但令人遗憾的是,实际上,通常并非如此。

忽略测试意味着积累技术债。随着时间的推移,开发流程将会逐渐恶化,因为开发人员会担心他们的代码会对其他部分的代码造成破坏。即便测试都能通过,我们依然会持续地发现bug,到底该如何避免bug的出现呢!Djikstra曾经说过:

测试从来不能证明没有故障,它所做的只能是展现它们的存在。

希望我们能够意识到测试是做什么的,并且能够明白如果没有它的话,软件开发是不完整的。最好要衡量代码覆盖度。代码覆盖度能够探测到哪些代码已经测试过了,哪些还没有测试。从数学上来讲,代码覆盖度可以表示为:

根据经验规则,覆盖度最好要达到85%或更高,测试至少要覆盖代码的85%。

我们并不能保证达到85%的代码覆盖率就是没有bug的系统,我甚至不敢说代码覆盖度会意味着更少的bug。不要产生误解,99.99%的覆盖率并不代表系统少了99.99%的bug。

与代码覆盖率同样重要的是应该将持续构建工具集成到代码库中,如Travis CI、Drone或Codeship。这样的话,对分支的任何变化都会触发测试。如果测试通过的话,那么它将会我们构建一个包,CI致力于最大化工作效率。

作为product owner,请不要在测试方面妥协!借助非常严格的测试,在生产环境测试我们的包的时候,曾经发现过P0级别的bug。这是在准生产环境(staging environment)和生产环境下,运行测试2到3次之后才发现的。

对工作进行同步

在所有的利益相关方之间对工作进行同步是非常重要的,这些相关方包括:product owner、开发人员、scrum master以及其他团队。实现工作同步的方式之一就是每天举行站会,这种会议会在每天的特定时间举行,每个人要讲述一下昨天做了什么,以及今天计划做什么。

如果你有远程团队成员的话,最好每天进行两次站立会议,一次在早上进行,另外一次在傍晚进行。通过这种方式,就能了解在远程的其他人计划做什么,并且能够在傍晚比较容易地得知其进度。

与之相关的另外一件事情就是跨团队的同步会议,这涉及到相关团队的成员。这个更大型的会议可以每两周举行一次,而不是每天都举行。比如,API团队以及portal管理团队之间所举行的会议就是这种类型,portal管理团队会使用API团队所开发的API。

站立会议还会进行一些关键性的讨论。如果会影响到相关团队的话,非常重要的一点就是尽可能多的通知相关成员。例如,如果要废弃数据库中的某一列,而这个列需要在多个应用间进行共享,那么提出废弃意见的人需要与其他相关的团队讨论该问题。

捕获更老的bug

你的系统可能已经存有bug,并且积累了一些技术债,这些问题可能会降低开发的速度,或者引起了客户的抱怨。针对这种情况,可以考虑规划整个sprint/星期都用来查找关键特性的各个组成部分,然后探讨如何一劳永逸地进行调试并移除bug。

在找到可能会有bug的特性之后,在to-do列表中将其记录下来,并为每个条目分配一个优先级。按照sprint的方式,每次只处理其中一项。如果你的团队中开发人员的数量足够多的话,那么对其进行分而治之是不错的方案:一部分人处理这些琐事(调试),而另一部分人就可以进行正常的story。

我们曾经遇到过来自财务部门相关特性的“bug”,这个问题实际上是由他们自己的错误操作所导致的,例如将钱转到商户的账户之后,错误地点击了取消按钮,而不是完成按钮。为了取消这样的点击,我们需要对数据进行多步手动变更,这最终消耗了我们很多的精力。但是,在进行了两个sprint的调试之后,我们再也不用进行这些令人郁闷的手动工作了,非常棒!我们已经忘记当时压力重重的状态了,当然,这样我们会更加开心!

自治

这是最后一件事情。强制开发人员从事某一项特性很可能会引入bug。开发人员应该自由选择从事某个新特性、进行研究还是修复某个bug,他们可以选择任意感兴趣的Story。

像Trello、Pivotal Tracker、Asana这样的工具甚至原始的白板都可以列出当前sprint要开发的所有特性,然后让大家自由选择他/她所感兴趣的Story。就团队来讲,只要Story符合公司的当前目标,就没有必要由管理人员来分派工作——让大家自行分派任务。

PS:如果你对所有的Story都不感兴趣,那么对你来说,这是另外一个“Story”了,HR也许会非常(不)高兴地找你聊聊。

但是,如果采用自治的策略,所有的人均不想开发某个特性的话,那么product owner需要进行讨论来解决这个问题。如果没人愿意做的话,那么需要结对来完成这个Story。在采用自治策略的情况下,我还没有经历过所有的人均不想选择某个Story的场景。

部署之前

Pull请求以及代码检查

在感觉完成某个Story的所有任务之后,你就可以提交一个merge请求或pull请求。对于具有多个互相关联团队的公司来讲,Pull请求会更加重要一些。

Pull请求就绪之后,Story的状态将会变为“代码检查中”。如果所有的事情看起来都没有问题,那么就会进行合并,然后,如果需要测试的话,product owner会在准生产环境手动测试Story。

代码检查不应该包含在某个Story完成状态的定义中,就像测试也不应该包含在其中一样。代码检查和测试应该是软件工程师的第二天性(second nature)。所有的Story在部署前都要进行代码检查和测试!所以在Story完成状态的定义中将其添加进去是多余的。

负责检查的人不应仅关注细节的错误,如变量命名不当或缺少空格,检查者应该关注逻辑错误、如何提升当前代码的性能、可维护性、安全性等方面。

如果你的Story采用结对编程的话,那么应该由不和你结对的人来进行代码检查。但需要注意的是,如果采用结对编程依然在代码中出现了逻辑错误,那是一件很令人尴尬的事情,两个人的大脑依然会产生带有bug的代码确实很让人难堪。

部署时

部署的内容要小,频繁部署

将你团队的部署计划进行分解。应该考虑每周部署一小块内容,而不是每两周部署一大堆特性,如果可能的话,可以部署地更加频繁。

一次性部署很多Story会让用户验收测试耗费太多的时间,用户一般只会觉得“哦,这个特性很棒”,而不是对其进行全面地测试。

另外,如果在这个很大的部署包中出现了bug,很难有效猜测bug产生的根本原因是什么。

在准生产环境测试,在公开环境测试

毫无疑问,更好更安全的方式是不要直接部署到生产环境中。我们应该在准生产环境进行UAT。如果在准生产环境的测试中发现了带有bug的特性,那么就将其排除在部署包之外。

在所有的事情均准备就绪之后,就可以在一台生产环境的机器上进行dry-run。dry-run能够让新特性在生产环境中运行,但是不会影响到很多人。网络工程师通常会将系统引导到选定的机器上。如果在dry-run环境下出现失败的话,就不要部署这个包!

当你确定所有的事情都达到预期的时候,就可以要求网络工程师将其部署到所有的机器上,使其完全公开。

在部署到所有的机器上之后,邀请一位终端用户来进行再一轮的测试。当然,在很多情况下,这也许不太可行,那也没什么问题。但是,如果你的用户来自公司内部,那么可以选择其中的一位用户进行一下最终测试。

如果遵循上述的所有规则的话,我们很少会在生产环境下发现bug,但是有些罕见的bug只会在生产环境下才会出现,我们曾经见过这种情况。所以,最后一分钟的测试时必要的。

部署之后

使用bug跟踪和监控系统

不要让客户成为第一个告诉你软件中存在bug的人。如今,我们可以非常容易地实现自己的bug跟踪系统,例如,在异常出现的时候,给开发人员发送一封Email。

像AppSignals、Raygun、NewRelic这样的现代化工具都是可以使用的,不过它们通常会有一定的成本。也有一些很好的开源工具可用,不过你需要自行将它们组合起来,如Munin、Telegraf、InfluxDB和Grafana。

通过使用这些工具,我们就能知道出现了某个bug,而不需用户预先填充一个报告表单。

工作回顾

到此为止,即便不是所有的Story,至少它们中的大多数都已经部署到了生成环境中。现在是进行快速工作回顾的好时机,与你的团队进行讨论,这包括product owner、scrum master以及其他的相关方,讨论一下最近这次部署哪些方面做得比较好,哪里出现了问题,如何在将来最小化错误的出现,以及如何提升团队的工作方式。

如果实现一个系统,允许开发人员在sprint的进行过程中就提交要讨论的回顾内容,那是很有用处的。通过这种方式,在进行回顾的时候,人们不用再浪费时间思考回顾点是什么,而是集中精力讨论所提交的内容。

甜点

作为product owner,不妨好好犒赏一下你的团队,(例如)如果连续三次部署都没有出现热修复的话,领他们喝个咖啡、去餐馆吃顿饭或者给他们放一天假。这会帮助他们提升积极性,让他们产生bug更少的代码。这里有个魔咒:要满足工程师,先满足他们的胃。

保持优秀和开放的文化

bug终究会出现,bug的发现过程可能会是这样子的:

  1. 业务人员找到你,并且对你说“嘿,我发现了一个bug。”
  2. “不,这不可能,这种事儿根本就不可能发生!”
  3. 不应该这样啊。
  4. 为什么会这样呢?
  5. 哦,我知道了,原来如此。
  6. 它是如何通过测试的呢?
  7. 对不起,这个特性不是我编写的!

在你的公司和团队中,保持一种开放的文化非常重要。

我们所能做到的就是尽可能减少错误出现的概率,而不是将其完全消除。如果你觉得其他的方式能够降低系统引入bug的可能性,从而能够避免热修复部署的话,请在评论区进行讨论。

我希望你们能够像我们一样,早就忘记了上一次热修复部署是什么时候的事情了。简而言之:因为出现bug所引起的电话呼叫越少,晚上就能睡得越安稳。

关于作者

Adam Pahlevi的乐趣在于编写具有可读性和高性能的代码。目前,他就职于一家印度尼西亚/日本支付网关公司:Veritrans,并担任软件工程师。他曾经出版过图书并发表过很多文章,还担任过workshop/技术大会的演讲者。他使用Ruby编程语言。

查看英文原文:The Way to No-Hotfix Deployment

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT