部署网站的完整性

Question

昨天，金融网站在客户端的部署被旧版本所取代，造成了意想不到的问题，停机时间几乎为12个小时。

我们了解到，他们IT部门的两个人正在为对方制造问题，这是由他们中的一个人做的，他们不想深入讨论细节。

这可能会导致财务上的差异和损失，但幸运的是没有。

它的人有充分的权利在服务器上，所以它不能控制在机器/操作系统级别。

那么，在ASP.NET内部是否有任何可能/选项来保护或确保部署的完整性？

例如，如果程序集的版本/哈希代码可以与数据库交叉检查，怎么办？

Answer 1

您应该添加一个健康检查页面或api到您的网站，并使用绿色/蓝色部署，以防止这种类型的问题。

健康检查页面，应返回该网站的版本。理想情况下，版本控制是在构建或部署服务器上自动完成的，不能手动更改。

首先部署到离线服务器集，并对它们运行集成/冒烟测试，包括检查健康检查网页返回的版本。

只有在这些测试通过后，您才能将这些服务器切换到活动状态，并将旧版本停用。

理想情况下，您的目标是将部署的人工组件简化为单击单个按钮。自动化所有测试和回滚过程。

Answer 2

解决方案是不允许开发人员永久地对生产服务器进行写入访问。如果需要访问是因为他们在开发人员的正常职责之外有职责，那么给他们一个单独的帐户来管理服务器。一个相当常见的审计要求，特别是对金融系统的审计要求，是要实现职责分离，以防止编写代码的开发人员成为可以部署代码的同一个人。有大量的部署自动化工具可以帮助您管理这一点，如果您将TFS用于源代码管理和构建，那么它们具有可用的版本管理，或者您可以将许多开放源码部署管理器集成到构建过程中。

创建一个限制允许版本的解决方案是与您的管理员之间存在大量不信任问题的一个迹象，这将在防止坏事方面提供最低限度的帮助。一个糟糕的演员，作为一个管理员，仍然会造成伤害，你的天气，所以，这样或不。这将防止意外的更改，但更好的解决方案是以这样一种方式管理权限，即无意中部署到生产中并不是一个现实的场景。在一切按计划工作和按计划推送新版本的时候，这样的系统会增加更多的开销，如果允许的版本自动更新成为部署过程的一部分，那么它就完全无用了。

你必须相信那些被授予管理员权限的人不会表现得不好，因为如果实际管理员想做的话，你就没什么办法阻止他们做任何事情。当不信任是默认的时候，它也创造了一个糟糕的工作环境。此外，您还需要适当地控制谁拥有管理权限，并确保只适合那些实际需要管理权限的人。