任何大项目在一年中的特殊时刻都会出现代码冻结，我的项目也不例外。在我们的环境中，我们使用微服务架构，其中每个团队负责整个编码-部署周期，其中部署意味着更改k8s部署。指向具有最新更改的新docker映像的Yaml文件。
然而，我们处理冻结的方法是不将任何更改合并到部署中。通过这种方式，k8s不会部署任何新的服务。但在我看来，这种方法并不理想，而且很容易被绕过，因为没有任何真正的阻碍，这只是一个共同的协议，我们不会合并这样的pr，这样我们就不会改变deploy .yaml。
这样，我的问题是，如果有一种已知的方法，在kubernetes配置或其他地方，我可以强制执行真正的冻结，并100%确定在此期间不会部署任何东西?
如果允许我在部署中继续合并更改就更好了。修改我的服务，但只有在冻结结束时才实际部署更改。
→如果你也不知道任何现有的方法，请留下你的建议，告诉我你认为如何做到这一点，因为我即将完成我在大学的最后一个项目，我认为这可能是一个有趣的话题……
这个问题的答案会根据一些参数而有所不同，但通常有2个主要的访问点可以改变生产，应该加以控制，以实现密封代码冻结-
- CI/CD管道——这是目前将更改部署到生产环境中最常见的方式。在我以前的公司，当我们想要防止开发人员在代码冻结期间部署更改时，我们会在代码冻结期间从CI/CD系统中删除生产凭证，这样即使将更改合并到master中，也无法部署更改。
正如@larsks在评论中提到的——如果你使用的是GitOps，你可能需要将当前的更改固定在git中的特定提交/标签上。 - 手动更改-如果组织中的开发人员可以手动更改产品，您也必须解决这个问题。您可以阻止手动访问，直到代码冻结结束，或者确保将策略清楚地传达给具有生产访问权限的每个人(因为手动更改不太可能无意中发生)
实现代码冻结时要解决的另一个问题是应用热修复程序和其他紧急更改的带外访问。当切断对生产的访问时，仍然应该有一条紧急路线允许对生产进行更改，并且它应该是简单和快速的-因为它通常会在压力和停机时间应用。