一般情况下我们都会避免在周五进行发布，毕竟大家都不喜欢

• 周五留下来加班发布，周五还是早点回去比较好
• 万一发出问题来了周六周日还要想办法去修复，休息的时间无形中被占用了

不过最近看到一篇文章观点很有意思，作者认为只要做的够好，在周五发布其实也不是什么大不了的事情。原文地址在这里，https://dev-tester.com/feel-free-to-deploy-on-friday/?utm_campaign=Software%2BTesting%2BWeekly&utm_medium=email&utm_source=Software_Testing_Weekly_147。 我稍微翻译了一下大意，也许它山之石可以攻玉。

省略前面若干字。

然而，我坚信，如果你想创建一个高质量的应用程序，大多数开发和测试团队的 "看在上帝的份上，不要在星期五部署 "的态度是不可取的。

为什么避免周五部署是一种不健康的质量控制习惯？

当一个团队像躲避瘟疫一样躲避周五部署时，通常可以认为他们对自己的的产品、流程或两者缺乏信心。这种不情愿通常源于组织需要知道或信任他们的应用程序已经准备好让客户使用。任何时候有人说 "我们不会在周五部署"，他们真正说的是 "我们不相信我们的应用程序或流程会在周五部署"。

从长远来看，这种想法并不能带来高质量的系统。团队并不把这些不确定性的作为一个表明他们需要专注于改进的信号。无论缺乏信任和信心是一个现实的问题还是一个想象中的问题，大多数团队都采取简单的方法来掩盖问题，而不是花时间去寻找改进问题的方法。他们想出了一些规则，比如周五不进行部署。

与其避免在周末进行部署，不如正面解决这些问题，加强现有的流程，让团队在任何需要的时候都能自由地进行部署。 作为一个开发人员或测试人员，如果不用担心因为在下班前要更新你的应用程序而使你的周末被打断，你会有什么感觉？

任何认真推动整个团队和产品的质量的组织必须在他们的公司中建立这种信任。虽然对你的系统完全有信心需要时间，但好消息是任何人都可以做到这点，无论他们认为他们的应用程序和流程在他们的组织中是多么的混乱不堪。下面的三步计划可以让你比你想象中的更快达到目的。

第一步：实现一个稳定的自动化测试集

自动化测试用例集合是任何想要快速构建和发布而不需要经常担心他们的应用程序的软件开发团队的必备工具。如果没有自动化测试套件，你就会严重削弱你的团队工作和部署的能力。如果你还没有给自己或你的团队一个空间来增加自动化测试覆盖率，你就会让自己处于不利的位置。

提升质量的第一步是用自动化测试去覆盖所有的关键路径，所以如果你是从头开始，请关注这一步。然而，比覆盖率更重要的东西是稳定性。即使有很高的覆盖率，如果你的测试自动化不断失败，也不会有什么帮助。如果你的测试用例很不稳定，你在任何时候都不会感到舒服，更不用说在星期五部署了。在测试覆盖率方面的工作，重点是建立一个强大的、可维护的测试框架，以保持你的团队长期的高信心。

另一个重点领域是你应该做什么类型的测试。根据你的应用程序的需求，你可能需要各种自动化测试的混合。有些团队写了几个单元测试就结束了，但今天的现代应用程序有很多变化的地方，你需要检查E2E、验证性能、确保安全性和可访问性等这些都只是冰山一角，提前计划哪些类型的自动化测试可以使你的组织受益。

知道你需要什么类型的测试和你想覆盖的领域。拥有一个稳定的自动化测试用例集和正确的测试组合将加强你的团队对你的应用程序和部署的信心。

第二步：不要忘记手动探索性测试

当团队养成了为他们的应用程序建立稳定的自动化测试的习惯，他们可能会对他们的测试套件在部署前捕捉问题的能力过于自信。通常，一种错误的安全感导致组织内的人认为他们不需要用测试自动化实践来执行额外的测试活动。这种想法与事实相差甚远。不管你的测试自动化习惯有多好，或者你的测试覆盖率有多高，你都不能忽视手动、探索性测试的重要性。

自动化测试只能做他们被告知要做的事情，在快速开发周期中很好进行功能回归。另一方面，手动和探索性测试将允许你观察自动测试的盲点，并在没有人想到的地方发现问题--所谓的 "未知的未知"。忽视测试的这一重要部分而依赖自动化，不可避免地会导致产品质量下降。

人工测试需要时间和精力来完成。一些团队，特别是没有专门的QA团队的小团队，往往在最后一刻才进行这些测试。与我合作的大多数初创企业只在重大部署前几天甚至几小时做探索性测试。有时这很有效，但你有可能匆忙完成这个过程，让bug遗漏到了线上。

理想情况下，手动探索性测试应该在整个团队的开发周期中持续进行并伴随着新的构建在staging环境上进行部署。让你的组织有时间做这种测试，你会发现自己在任何时候都不会担心部署的问题。

第3步：建立一个自动化的构建和部署流程

在构建软件的组织中，开发和发布周期的一个部分经常被遗忘，那就是构建和部署过程。在我工作过的一些地方，构建和部署一个新的版本几乎感觉像是一个神秘的过程，只有少数被选中的人才能完成。他们的部署通常由一个漫长的步骤组成，按照精确的顺序和几乎完美的时机进行。如果执行这种仪式性行为的人在途中寄掉，这个过程的脆弱性可能会在瞬间使整个应用程序崩溃。

我描述这个过程的方式可能略显夸张，但却非常接近事实。我合作过的许多公司都有不必要的复杂部署程序。当被问及原因时，一些团队试图证明为什么需要这样做，但他们回答背后的潜台词其实是 "我们一直是这样做的，所以我们从未改变过"。常见的原因是，很久以前有人创造了这个复杂的过程。既然它是有效的--不管这个过程变得多么微妙或曲折--他们从来没有费心去改善现状。

如果你的团队必须执行多个步骤来构建和部署你的应用程序的新版本，那么你就对你的组织造成了巨大的伤害。无论你的整个系统包含多少模块，你都可以将几乎所有的发布过程自动化--甚至将其浓缩为一个命令。如今，我们有大量优秀的工具，从Jenkins到AWS CodePipeline到CircleCI和无数其他工具，使构建和部署过程自动化变得非常简单。你的组织没有任何借口可以避免自动化部署。

部署过程中一个同样重要但被遗忘的部分是回滚失败的部署。尽管有一个经过良好测试的自动化过程，它仍然可能由于许多不同的原因而失败，从糟糕的代码被合并到你的应用程序的基础设施的故障。大多数团队发现他们没有任何回滚策略，当部署失败时，他们的应用程序就会停机。在这种情况发生之前，制定一个适合你的情况的回滚策略，并经常测试，以确保当墨菲定律发生时，你不会感到惊讶。

总结

这篇文章的目的不是让你的团队每周五进行部署，而是让他们在需要时可以毫无顾虑地进行部署。自信部署而不用担心某些幺蛾子会发生的能力，会让每个开发人员和测试人员在他们的项目周期中不用担心太多。如果我们幸运的话，也许我们会看到更少的memes在我们的LinkedIn feeds上乱窜。

总之作者的观点是如果你够强，什么时候部署都没问题。然而时间总是自己的，为了不必要的节外生枝，还是建议大家在周五下班前或者下午不要进行部署，多一事不如少一事，不在周五部署不是真理，而是生活。