是否有必要在某些时候禁止部署到生产中？ 还是
#NoDeployFriday运动成为没有全面集成测试和持续部署的时代遗物？
在团队中，您可能会面临同样的困境。 谁是对的，谁应该受到指责？ 是在星期五放弃部署是降低风险的合理策略，还是一种不良的文化使我们无法创建更好，更稳定的系统？
丁丁
我敢肯定，那些拥有“联系”的好运气的工程师会因为所有星期五的更改而中断工作。 我也处于这种情况。 当您与家人或半夜离开时打一个电话，通知您应用程序崩溃。 进入计算机并查看快速增长的日志后，很明显，所有事情都被罕见的未处理异常破坏了。 真恶心
分析表明，对于导致失败的情况，没有编写任何测试，显然是因为认为它不太可能。 在与其他工程师进行了一系列漫长的通话以寻求更好的方法来回滚所做的更改并修复所有问题之后，系统再次开始工作。 唷。
星期一举行五次会议。
“
让我们在星期五停止部署。然后在周末一切都将稳定运行，而下周我们将在发布各种版本后保持警惕 。”
大家点头。 如果在周四中午之前某项未运行，则将一直等到周一早晨。 这种方法有害还是有用？
如您所知，Twitter声明通常是非常主观的。 尽管禁止星期五发布似乎是合理的，但有人会很快指出，由于平台的脆弱性（这是由于不良的测试和部署过程所致），这只是a脚。
甚至有人建议您比周末本身更喜欢安静的部署：
其他用户认为，功能标记的实现可能是一种可能的解决方案。
该用户认为，由于当今可用的流程和工具，不应出现有风险的部署问题。
谁来做决定？
所有这些意见交换表明，作为工程师社区，我们可以强烈不同意，不一定彼此同意。 谁会想到的。 这种情况可能还表明，＃NoDeployFriday的整体情况包含这样的细微差别，这些细微差别在Twitter上没有很好地反映出来。 是否所有人都必须进行连续部署，否则我们“做错了”吗？
在做出这样的决定时，有一个心理方面。 对星期五发布的敌意来自于害怕在一周中犯错误（由于疲劳或仓促），这可能会危害大多数员工休息两天的情况。 结果，包含潜在问题的星期五承诺可能会破坏一整个人的周末：值班工程师，其他将远程帮助解决问题的工程师，以及可能必须恢复损坏的数据的基础架构专家。 如果发现故障很严重，则该公司的其他员工也可能参与其中，他们需要联系客户并最大程度地减少损失。
采取理想主义者的立场，我们可以假设在一个理想的世界中，拥有完美的代码，完美的测试覆盖范围和完美的QA，没有任何变化会导致问题。 但是我们是人，人们容易犯错误。 在开发过程中，总会有一些奇怪的边界案例没有被关闭。 这就是生活。 因此，＃NoDeployFriday运动至少在理论上是有意义的。 但是，这只是一个盲目的工具。 我认为有必要评估根据情况做出的更改，并且有先验的是必须从我们部署任何一天（甚至是星期五）这一事实出发，但同时应该能够隔离那些要等到星期一的更改。
我们可以讨论一些问题。 我将它们分为几类：
- 了解变化的“破坏半径”。
- 部署过程的合理性。
- 自动检测错误的能力。
- 解决问题需要多长时间。
现在让我们讨论。
了解“破坏半径”
当有关周五发布的在线矛头再次开始中断时，他们总是会忘记重要的内容-有关更改的本质。 代码库中没有相同的更改。 一些提交仅控制界面一点，仅此而已。 其他的则重构了数百个类而不影响程序的功能； 还有一些更改数据库架构，并对实时数据消耗过程进行重大更改； 第四个实例可以重新启动一个实例，而第五个实例可以启动所有服务的级联重启。
通过查看代码，工程师应该对所做更改的“破坏半径”有所了解。 代码和应用程序的哪一部分会受到影响？ 如果新代码崩溃，会发生什么？ 只是单击将引发错误的按钮，还是会丢失所有新条目？ 是对单个隔离服务进行更改，还是将同时更改许多服务和依赖项？
我无法想象谁会拒绝在一周的任何一天以较小的“破坏半径”和简单的部署进行更改。 但是同时，重大更改（尤其是与存储基础结构相关的更改）应该更加谨慎地进行，也许是在在线用户较少的时候。 如果将这样的大规模更改并行运行以测试和评估其在实际负载下的工作效果会更好，而且没人会对此一无所知。
在这里，您需要根据情况做出决定。 每个工程师是否都知道生产环境中的变化的“破坏半径”，而不仅仅是开发环境中的变化？ 如果没有，为什么？ 是否可以改善文档，培训和代码更改在生产中的影响的显示？
“破坏半径”小吗？ 在星期五发射。
“破坏半径”大吗？ 等到星期一。
部署过程的合理性
降低风险的一种方法是不断改进部署过程。 如果要启动应用程序的全新版本，专家仍然有必要知道要运行哪个脚本，哪个文件以及在哪里复制，那么该是时候进行自动化了。 近年来，这方面的工具已向前迈进了一大步。 我们经常使用
Jenkins Pipeline和
Concourse ，它们使您可以直接使用代码设置组装，测试和部署管道。
完全部署部署的过程很有趣。 它使您可以退后一步，并尝试抽象出从拉动请求初始化到应用程序投入运行之间应该发生的情况。 例如，上述工具中的代码中所有步骤的描述将帮助您概括步骤的定义，并在所有应用程序中重用它们。 另外，您会注意到自己曾经做出并与之相适应的一些奇怪或懒惰的决定，这对您来说很有趣。
对于每个阅读了前两段并以“当然！ 我们这样做已经很多年了！” 我可以保证另外9个人展示了他们的应用程序基础结构并做鬼脸，从而实现了将系统转移到现代部署管道所需的大量工作。 这意味着要利用现代工具，这些工具不仅可以执行连续集成，还可以让您不断向产品提供错误，工程师只需按一下按钮即可进行调试（如果您足够勇敢，甚至可以自动进行调试）。
改善部署输送机需要参与和适当的人员-绝对不是附属项目。 一个好的解决方案是突出一个团队来改进内部工具。 如果他们仍然不了解现有问题-并且他们可能知道-那么您可以收集与发布过程相关的最痛苦情况的信息，然后确定优先级并与其他人一起解决。 但是，情况肯定会有所改善：代码将以更快的速度运行且问题更少。 越来越多的人将能够学习更好的方法并自行进行改进。 随着情况的改善，将在团队中分发方法，并且这个新项目将正确完成，而不会照搬旧的坏习惯。
从合并的那一刻起，对提交的拉取请求应该是自动化的，因此您甚至不必考虑它。 这不仅有助于隔离QA中的实际问题，因为唯一的变量是更改后的代码，而且使编写代码更加有趣。 调试是分散的，这会增加个人的自主权和责任感。 反过来，这又导致了有关何时以及如何推出新代码的更慎重的决策。
可靠的输送机？ 周五推出。
手动复制脚本？ 等到星期一。
检测错误的能力
代码开始工作后，调试不会停止。 如果出了问题，我们需要了解它，建议我们了解此事，而不必自己寻找信息。 为此，您需要自动扫描应用程序日志中的错误，明确跟踪关键指标（例如，每秒处理的消息数或错误比例），以及一个警告系统，该通知系统告知工程师关键问题并显示某些指标的负面趋势。
操作始终与开发有所不同，工程师需要监视系统某些部分的操作。 您需要回答有关每个后续更改的问题：它是加快还是降低了系统速度？ 有多少超时？ 是受处理器还是I / O限制？
有关度量标准和错误的数据应传输到警告系统。 团队应该能够确定哪些信号表示负面情况，并自动发送有关该情况的消息。 对于我们的团队和最严重的事件，我们使用PagerDuty。
测量生产系统指标意味着工程师可以查看每次部署后是否有所改变，无论是好是坏。 在最坏的情况下，系统会自动将问题通知他人。
好的监控，通知和应召唤专家？ 在星期五部署。
通过SSH手动查看日志？ 等到星期一。
解决问题需要多长时间？
最后，主要标准是解决问题将花费多长时间。 这部分取决于所做更改的“损害半径”。 即使您的部署管道不完善，某些更改也很难快速修复。 回滚数据提取系统和搜索索引方案中的更改，除了修复某些代码行之外，可能还需要进行费力的重新索引编制。 CSS更改的平均部署，验证，更正和重新部署可能需要几分钟，而对存储库的重大更改可能需要几天的工作。
对于部署管道中的所有工作，这些工作在宏级别上可以提高更改的可靠性，没有更改是相同的，因此您需要分别评估它们。 如果出现问题，我们可以迅速解决吗？
通过一次还原提交就可以完全解决吗？ 在星期五部署。
如果出问题了，会有很大的困难吗？ 等到星期一。
为自己思考，为自己决定
我在#NoDeployFriday的职位是什么？ 我认为这完全取决于版本。 具有“回滚半径”且易于回滚的较小更改可以随时随地进行部署。 对于较大的更改，必须在生产系统中严密监视其影响，我强烈建议等到星期一。
实际上，由您决定在星期五进行部署。 如果您使用的系统脆弱且脆弱，那么最好在您完成改善部署过程所需的一切之前避免使用星期五。 只要确定要执行此操作，请勿将其清除。 拒绝星期五的发布是弥补临时基础结构缺陷的一种正常方法。 对于企业而言，这是合理的损害减免。 但是，如果这条规则涵盖了持续存在的缺陷，那就不好了。
如果您不确定更改将产生什么影响，则将其推迟到星期一。 但是，请考虑下一次可以做什么以更好地了解此效果，并为此改善相关的基础结构。 与生活中一样，每个决定都有自己的细微差别。 解决方案没有分为“黑色”和“白色”，也没有分为“正确”和“错误”：在我们为业务，应用程序和其他应用程序竭尽所能，改进系统的同时，我们也将一切做好。
成功部署。