为什么不在星期五部署?[关闭]


94

Joel在StackOverflow 24号播客中提到,FogCreek公司的政策是在周五不发布软件。但是,他没有详细说明原因。

我同意。在我的雇主处,我们在周四晚上进行部署。因此,我们有星期五来清理所有错过质量保证(QA)的错误。

但是,我的经理建议,如果质量检查没有足够的时间在发布之前测试软件,我们将在星期五晚上进行部署。我说,人们的周末计划怎么样?而且,如果我们在星期五晚上进行部署,那么我们将不得不在星期六工作以清理所有遗漏的错误,这很糟糕。

那么,为什么不在星期五发布软件呢?

*我们可能(不确定)需要做出这样的假设:一个时区中有一个核心软件开发团队来部署其公司的核心Web应用程序。


11
如果是我的流程,那么它将在周三进行部署,一周中的中午将给您几天的时间来解决周末之前的问题
CVertex 2010年

3
苹果通常在星期二进行部署。
mouviciel 2010年

2
关于星期二的好处是,您可以在星期一进行最终检查,也可以进行练习部署,因此每个人都在同一页面上,它使您在一周的剩余时间里可以处理所有出现的事情。在星期五之前,您将知道该周末是否必须工作。
Mike DeSimone 2010年

7
我看不到这与编程无关。编程代码部署的最终结果不是吗?
womp 2010年

1
@womp如果我遵循您的推理,那么部署代码最终就是要实现一些面向业务的需求。这应该证明任何与业务相关的问题吗?
Pascal Thivent

Answers:


87

这不只是一个错误的问题。可能还有其他相关的支持负担-向用户说明新功能,监视没有性能问题。

新版本通常意味着短暂的支持活动高峰-因此安排在可用人员较少时(或花费更多时间花费时间)进行安排是一个坏主意。


6
乔恩·斯凯特(Jon skeet)随时发布代码,..对吗?
马特2010年

15
@Matt-如果一天从星期五开始,那么它将不再如此,因此当Jon发行软件时,Jon Skeet不会根据日历调整他的发行时间表...日历会根据他的发行时间表进行调整。
Newtopian 2010年

2
@Newtopian:你得到了它与查克·诺里斯混合,乔恩斯基特只是谷歌机器人
Niteriter

5
@Matt,更正:Jon Skeet从不在Debug配置中编译代码,仅在Release中编译。编译器完成后,新版本将立即交付给世界各地的客户。他喜欢那样。

2
我的工作室似乎有一个在星期五上班的可怕习惯。我可以说,事实上,老板在周六/周日错过了一些东西时,接到了大多数生气的客户电话。(星期五永远不会
发射

50

永远不要在星期五部署,因为:

  1. 这是周末,所以人们不那么聪明
  2. 这是周末,所以没有人可以修复错误
  3. 这是周末,所以没有人可以回答问题
  4. 周末结束了,那为什么还要部署呢?

1
KIIS-您再好不过了。..
R Claven

46

您几乎回答了自己的问题。这是一个简短而甜美的理由:如果您在星期五发货,并且有错误将其投入生产,那么通常在下一个星期一之前,没有人来修复它或与客户交谈。在最坏的情况下,这可能会损失几天的收入。


1
同样在这里。我正在为一家制造公司开发内部软件,因此没有外部客户。但是我们的用户在周末和夜班工作,因此在星期五晚上进行部署将是我们最糟糕的事情:-)
Christian Specht 2010年

8

我们避免在周四周五发布代码-没有人愿意在周五花费大量时间来找出关键任务的错误,而且即使我们在一天之内完成修复,也至少要等到第二天才能发布,这意味着要么在周末工作,要么直到下周才固定。


6

这取决于您的目标人群。我们主要在星期五部署。我们的基于浏览器的产品在全球范围内被客户使用,但主要在办公时间内使用。这意味着,如果我们要确保不影响任何客户(印度和中东在星期六不会下班的话),除了星期天早上,我们实际上没有其他时间,但是通常我们会“妥协”并在星期五下午部署。

如果以前曾在约会网站上工作过,我们理想地想在星期二左右部署新内容,因为活动在周末左右达到高峰,而在星期一午餐时段则达到了峰值。

无论如何,它归结为2个注意事项。1.什么时候对您的客户造成最少的破坏(如果是Web应用程序),以及2.什么时候最适合与紧急修复关键错误的开发团队一起使用。

如果您担心开发人员在本周末将变得草率,那么您的质量检查流程可能会太短。


4

我们通常在星期二进行部署,然后我们可以在一周的剩余时间内解决任何问题。这也取决于行业,如果周末没有工作,也许可以在周五晚上部署,但是如果他们有工作,那么这不是一个好主意。

为此,人们倾向于在星期五(已经考虑到那热的日子)和两天的假期之前草率地去;-)


4

这实际上取决于您的应用程序以及周末的忙/忙程度。

我们通常不在星期五部署软件,但通常在星期六或星期日部署软件。我们发现星期天早上特别有利于最大程度地降低发行版的影响。

这实际上取决于您是否要尽量减少发布版本所需的任何停机时间的影响,还是减轻任何潜在的错误。

在客户实际使用该系统之前,您几乎不会看到任何错误(在大多数情况下),因此,如果周末使用率较低,则在星期五进行部署等同于在星期一早晨进行部署。

另一方面,诸如在线购物之类的东西在周末往往使用更多,因此,绝对建议您不要在星期五部署其中之一。

这也取决于您的非工作时间支持政策。如果您有待召集的人可以回滚该软件,则风险较小。不过,我还是希望在工作周中这样做。

我们通常在星期二至星期四部署内容,而不是避免在星期一(我们最忙的一天)和周末(这时可能会发现一个错误而不引起注意的问题)


4

应该在星期五进行部署,以便您有整个周末的时间来清理它并修复错误,然后团队其他成员在星期一注意到您的疏忽。


3

除非我也计划在周六去办公室验证其正常工作,否则我永远不会计划周五的部署,如果您由于滑倒而最终在周五部署,则极有可能被赶到,所以最好等待,让大家在周末冷静下来,然后在经过上午的评论后于星期一发货。

如果您的部署工作在周末进行,那么从星期五晚上开始可以为您提供良好的开端,因为办公室通常会提早清理一下,因此总的系统负载会比星期一早上的要低。


2

我曾与一家制定在周五进行部署的政策的公司合作;他们在以色列,星期六通常是工作周的最后一天。无论如何...

在我的上一家公司,政策是在周二和周四的午餐时间之前向Ops提供部署程序包。这意味着他们有半天的时间来解决这个问题,如果在上线质量检查的最后阶段出现任何问题,请稍作调整。(其他任何质量检查都可能在一周中的任何时间发生,因为它没有生效。)

如果Ops有时间做,可以随时发布到除了live之外的任何环境中(当然,无论如何都应事先预定),但永远不要发布:

星期一-不好,您刚刚从(希望是一个不工作的)周末回来,而上周的所有工作都没有出现在您的脑海中。星期三-通常是一周中效率最低的一天,是“工作的中间”一天。如果您的广告位是星期二,但由于错误而错过了,则星期三可能是一个错误的选择,因为您没有提供足够的时间来修复和测试这些错误。星期五-加油。认真吗 是星期五。如果这确实需要解释,那么您没有足够的经验来担任您所处的管理职位。但是,严重的是,这是因为在星期五进行部署意味着自愿让您的客户在周末来现场测试您的工作环境。对我来说,这胜过您可能会排队等待的愚蠢行为。


1
我同意星期五的运输不好。我希望StackOverflow社区给我可靠的理由,因此我可以轻松地说服我的经理远离周五部署的任何可能性。并希望该线程将帮助其他软件开发人员,例如我,避免可怕的星期五部署:)
Bill Paetzke 2010年

0

我们很幸运能够善用时差,我们的办事处遍布全球。因此,在对客户进行更新时,我们会将其安排为对客户一夜之间完成,以最大程度地减少对客户的影响。

当您控制软件的实施和部署时,此方法效果很好,但是在网站上发布完全是另一种动物。正如其他人指出的那样,请确保您留出时间:

  1. 支持可能出现的怪癖和错误
  2. 在过渡中支持用户
  3. 最后一分钟的热修复
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.