改进部署管道可以降低部署失败的整体风险，而不是选择哪一天会是糟糕的一天。
译自 Deploy on Friday? Moratorium Doesn’t Achieve Admirable Goal，作者 Steve Fenton。
避免周五部署的驱动力是，虽然目标令人钦佩，但可以通过其他方式更好地实现。然而，组织更可能在周五而不是周一进行部署，这表明业界并不认同不应该在周五部署的神话。
虽然你过去经常听到关于最佳实践，但你可能已经注意到，行业专家对这个词越来越谨慎。最佳实践确实存在，例如使用版本控制而不是网络共享来存储源代码。许多其他实践最终只是好的，而不是最好的。
最佳实践的理念是，它们是软件交付的基石，没有它们工作可能会造成危害。另一方面，好的实践是可选的。你不必采用所有好的实践，因为你可以从所有经过验证的解决问题的方案菜单中选择一个精心选择的选项来覆盖风险区域。
如果你的最终用户报告了逃逸的错误，你可以应用一个或多个测试和监控好的实践，以便在用户体验到这些问题之前捕获类似的问题。你可以查看不同的测试和监控方法，并尝试其中一种方法来查看其有效性。在你采用一种实践之后，问题可能会得到解决，或者可能需要几种互补的方法来改善这种情况。
至关重要的是，一旦你解决了问题，就应该停止添加实践。添加不需要的进一步实践会导致不必要的复杂性，这可能对软件交付有害。
最后，有一些实践在追求时是有害的。这些通常是出于好意，并且几乎总是被当作最佳实践来呈现，但实证证据和严格的研究证明它们是错误的。这些有害实践的例子包括 Gitflow、大批量工作和重量级的变更审批流程。
识别反模式的一个好的启发式方法是，你被告知某件事是最佳实践，但它听起来不像软件交付的基本基石。如果有任何疑问，请寻求来自经验丰富且有交叉参考可靠研究的人的可靠建议，例如 Accelerate 的“DevOps 状态报告”。（2024 年的报告将于 10 月发布。）
牢记实践入门，让我们考虑一下我们是否应该在周五部署。在最近的CrowdStrike 停机之后，许多人建议如果他们没有在周五部署，情况可能会得到改善。
很难理解为什么在周四部署会改善 CrowdStrike 的问题。我们难道不应该在周四乘坐飞机或使用电脑吗？我们可以通过查看禁止周五部署的感知益处来探索这个令人困惑的说法。
我询问了人们为什么我们应该避免周五部署，看看这些说法是否有道理。作为一个被强有力的论据改变了对制表符与空格看法的人，我相信如果有一个令人信服的论据，我可以被说服。
关于周五禁令的最常见论据是，它可以让开发人员在周末与家人共度时光，而不是为了恢复服务而工作。
这只有在你从失败的部署中恢复的时间几乎正好是一天的情况下才成立。如果需要超过一天的时间，你将在周六工作以从周四的部署中恢复，除非你也停止周四的部署。如果你可以在不到一天的时间内恢复，你可以在周五部署，并在周六去海滩。
你的恢复时间越长，你需要在过去部署的时间就越早，以避免在周末工作。例如，如果你从失败的部署中恢复需要一周时间，你需要在上周五部署以避免在本周末工作，但这确实意味着你必须在上周末工作。
现实情况是，恢复时间并不恒定。有些问题比其他问题更容易恢复。拥有恢复时间的分布意味着你正在采取一种概率方法来保护周末。如果你每天都部署，你会发现周五部署比周一部署更有可能扰乱周末。 当您采用这种方法时，您会发现可以对部署管道进行许多改进，从而降低中断的可能性。禁止部署不会降低您的整体变更失败率，只会意味着您的周一部署将更频繁地失败。改进您的部署管道可以降低整体部署失败的风险，这比仅仅选择哪一天会是糟糕的一天要积极得多。
工作与生活的平衡适用于周一晚上，就像它适用于周末一样。人们一周中的每一天都有个人承诺，从接送孩子上学到生日和周年纪念日，再到与老朋友见面的安排。这些都是重要的，因此进行减少部署失败的改进比将它们转移到不同的工作日更能保护工作与生活的平衡。
有一些理由要避免在特定时间部署，但这些理由与您的行业有关。例如，在零售行业，您会避免在商店营业时更新收银机上的软件。在您为顾客结账并有一排顾客在等待时，您不需要新版本的软件。
您的发布计划将制定部署时间和避免部署时间。它还将记录培训零售店员工的流程，以便他们在升起卷帘门之前了解发生了哪些变化。
通过考虑受我们软件影响的人，我们考虑的人比仅仅考虑我们自己要多得多。如果我们想到所有依赖我们软件的人，我们可以考虑一千倍更多人的工作与生活的平衡。理想情况下，我们永远不会出现部署失败，我们的推出不会有任何停机时间。实际上，事情有时确实会出错，拥有强大的恢复时间可以最大程度地减少影响。
研究表明，有一些功能可以让您更频繁地部署，同时降低失败率。表现最好的公司每天部署多次，包括星期五。
为了了解星期五部署禁令是否影响了真正的组织，我分析了超过 3200 万次部署，以查看它们是在何时进行的。数据涵盖了所有组织规模和许多行业。事实证明，星期五部署比星期一部署更常见。
这是一个好消息，因为它表明避免星期五的迷信在实践中几乎没有影响力。
您的组织决定不想在星期五部署是完全可以接受的，尽管对原因的一些好奇心要么会发现有趣的领域知识，要么会突出显示您可以在部署管道中改进的一些事情。不太吸引人的是将“不要在星期五部署”作为最佳实践进行广播。
众所周知，以小批量工作可以提高软件交付性能。如果您遵循持续交付和 DevOps，您可能每天部署五次。如果您排除星期五，您将积累一个比正常批次规模大五倍的周一部署。您选择将性能从“按需”降级为“每天”。
您部署得越连续，停止一天的想法就越糟糕。这意味着“不要在星期五部署”运动的成员，在没有特定组织背景的情况下，选择了平庸。
不要仅仅开始在星期五部署。将此作为评估您的情况的机会，了解用户和客户，并开始改进您的软件交付能力。