软件部署日的选择受内外因素影响。需考虑最终用户、环境类型、回滚计划、反馈周期、自动化程度、团队福祉、组织成熟度及风险承受能力。健全的流程和自动化至关重要。
译自：Friday vs. Midweek: When's the Best Day to Deploy?
作者：Joanna Wyganowska
选择合适的软件部署日并不像人们想象的那么容易。有许多因素会影响这个决定，包括内部和外部因素。本文介绍了DevOps从业者关于他们认为的最佳软件部署日的观点。
Luke Philips是 Patrick Consulting 的所有者，也是一家大型出版公司前任 Staff Software Engineer，他开玩笑说，他所在组织的经典做法是在周五部署，然后用整个周末来修复故障。
但抛开玩笑不谈，避免客户受到部署问题的影响，对于选择正确的软件部署时间至关重要。
考虑对最终用户的影响
医疗保健组织的现场服务工程师 Matt Acree 表示，周五的部署通常是出于尽量减少对用户潜在负面影响的需求。如果你认为影响将是最小的，并且希望获得用户问题的实时报告，那么最好选择周中部署；但是，如果预计可能会出现重大停机，那么他建议在周五下班后进行部署，并让你的随叫随到团队做好准备。
生产环境 vs. 非生产环境部署
Infosys 的 DevOps 工程师 Rahul Kumar Verma 也倾向于选择周中进行部署。他建议将生产环境部署计划在周中，而不是周五，正如他所说，“如果生产应用程序出现故障，为什么要自找麻烦呢？” 由于周五是非生产日，你可以完成更新并为下周一做好准备。
但是，对于非生产环境部署，他说应该根据需要进行部署，包括周五。PilotPlan 的创始人 Niall Hatton 也表达了同样的观点。正如他所说：“不要在周五部署到生产环境。但其他任何环境，任何一天，任何一周都可以。”
健全的回滚计划的重要性
一家大型医疗保健技术公司的 DevOps 总监 Mandeep Sharma 驳斥了避免周五部署的神话。他认为，如果团队不在场时出现问题，这只是一种为了更安全的权宜之计。他提倡健全的部署流程，该流程可以通过自动化/SRE 来检测故障。他经常看到的缺失步骤是健全的回滚计划，这可以使部署更安全。
为什么快速反馈周期至关重要
Octopus Deploy 的首席软件工程师 Orion Edwards 认为，选择部署日取决于你的反馈周期有多快。例如，如果你的系统需要 12-24 小时才能跨区域部署，那么在周五下午部署可能意味着直到周六晚些时候才能到达所有区域。如果出现任何问题，这可能会导致一个糟糕的周末。
即使你的部署实际上是即时的，但如果你拥有全球客户群，由于时区原因，周五下午的部署可能要到周六才会开始影响关键客户。但是，如果你有快速的反馈，并且了解潜在的本地/全球影响等因素，你可以随时部署。
部署自动化如何推动成功
欧洲一家银行的工程经理 Paul Davies 同意，选择正确的部署日仍然存在争议。从他的角度来看，这关乎对发布到生产环境的信心，并且有许多工具和策略可以支持它。这些工具和策略的范围可以从手动 QA 测试人员和暂存环境到各种自动化测试、金丝雀部署和高级自动化监控。
最重要的是，来自生产用户的即时反馈，他们会注意到是否有任何问题。此反馈会返回给工程团队，然后他们可以回滚更改或应用修复程序。
正如他总结的那样，理想情况下，我们应该能够在周五下午 5 点进行部署，并确信我们的自动化测试和监控将捕获任何问题。然后，可以在生产环境中自动回滚不良的部署，并创建一个错误工单，以便在下一个工作日解决。然而，实际上，从他所看到的来看，这种程度的自动化（和信任）极其难以实现。因此，如果你喜欢无压力的周末，最好不要在周五下午做的最后一件事是部署到生产环境。
考虑团队福祉
Uitware 的 DevOps 工程师 Kateryna Bakhmat 认为，在团队福祉方面，避免在周五进行部署是一种最佳实践。到周末时，工程师和其他人员通常会感到疲倦，这可能导致更容易发生错误的情况。此外，如果部署包含错误（这种情况时有发生），则可能导致工作量增加和工作时间延长 - 在某些情况下，甚至可能需要在周末加班。
她还指出，每种情况都不同，有时有必要在周五进行部署；但是，根据她的经验，最好在周五完成其他任务，然后在周一以清醒的头脑进行部署。
组织成熟度和资源如何重要
全球 IT 服务提供商的安全架构师 Barbara Teruggi 将成熟度级别列为决定何时是部署软件的正确时机的关键因素。她还指出，公司规模是一个重要因素。中大型公司可能有足够的预算进行自动化，并且可以在周末安排必要的专业人员值班或待命；但是，小型公司或初创公司可能没有。
同样重要的是你的公司构建什么样的系统/软件，以及你的客户何时使用它的频率最高。她建议避免在高峰使用时间部署到生产环境。另一个重要因素是你正在部署的更改的严重程度。如果出现问题，会对你的客户造成多大的影响？你是否依赖其他方进行部署或测试？如今，许多公司将其服务与其他公司的服务集成在一起。她的观点是，至少在目前，必须始终让人参与其中。
即使拥有世界上所有的自动化，如果你的部署中没有合适的人员并且对所部署的内容有正确的了解来检查它，她也不建议在周五部署任何关键内容。
为什么风险承受能力驱动部署决策
YouTube 的高级软件工程师兼站点可靠性工程 Yury Fedorov 对关于最佳软件部署日的想法进行了精彩的总结。在他看来，这个问题触及了技术领域一项重大挑战的核心。简单的答案是，没有任何东西是真正 100% 可靠的，因为无数因素可能导致失败，而且这些因素通常是相互依存的。你可以这样理解：一个复杂的系统就像一个叠叠乐塔。即使每个块（一段软件、一台服务器或一个进程）都是完美的，一个区域的微小移动也可能导致整个塔倒塌。
他提供了以下一些导致这种不完善的因素的细分：
- 复杂性： 随着系统的增长，它们的互连部件（软件、硬件、基础设施、依赖项）也在增长。一个区域的更改可能会对另一个区域产生不可预测的连锁反应。
- 人为错误： 人们会犯错误。无论是编码错误、服务器配置错误还是命令中的拼写错误，人为因素都是潜在故障的持续来源。
- 外部约束： 预算、时间和团队知识等现实世界的限制都会影响系统的构建和维护方式。有时，必须做出妥协，这会带来风险。
- 流程和运营： 即使有最好的意图，流程也可能存在缺陷。例如，在周五下午部署重大更新似乎很有效，但如果周末前出现问题，则几乎没有时间修复。这就是为什么许多组织制定了明确的政策来反对此类部署，选择在某些情况下优化安全性而不是速度。
虽然 DevOps 等方法旨在实现自动化 并减少许多此类风险，但它们无法消除这些风险。相反，它们专注于减少故障发生的频率，更容易检测到故障，并在不可避免地发生故障时更快地恢复。
正如你所看到的，组织在决定何时部署时需要考虑许多因素。自动化和健全的回滚计划是成功的关键；但是，需要考虑的是风险承受能力以及负责部署的团队的负担。
总而言之，正如我们在 Octopus 所说的那样，“每天都是部署软件的好日子，即使是周五”——只要你的流程是可重复且可靠的。
