组织计算机的管理员通常非常谨慎地决定允许在计算机上安装哪些程序。他们通常会禁用自动更新，而是手动审核更新，并在确定更新不会破坏任何用户工作流程的情况下将其推送到计算机。
但是 Chrome 却有自动频繁更新的倾向。我不知道 Chrome 是否提供了“门控”更新，允许组织管理员在将更新发布到组织之前对其进行测试。但我可以想象它确实提供了。
我的问题是：那些在用户不知情的情况下自动、频繁且频繁地更新的应用程序，组织计算机的管理员如何看待它们？如果我要创建这样的应用程序，这些管理员是否需要关闭自动更新的能力？或者他们是否愿意事先检查更新？
我意识到这个问题可能太宽泛，并且严重依赖于特定的组织。我对“最佳实践”和“一般规则”的答案更感兴趣。
背景
我之所以问这个问题，是因为持续部署的概念在软件开发中越来越流行。当你控制部署软件的服务器时，使用服务器组件会容易得多。但是如果软件直接安装在客户端站点上，就会变得困难。我相信 Chrome 正在进行持续部署，这就是为什么它严重依赖新版本的自动更新。在极端情况下，这些更新可能是每日增量构建。我想知道，如果我要销售每周甚至每天更新的应用程序，我应该期待管理员遇到什么样的阻力？这种自动更新系统应该为管理员提供什么，以使他们更轻松。因为如果应用程序破坏了他们的更新工作流程，我不希望管理员违背应用程序的指示。
答案1
以 Google Chrome 为例，这个问题通过三种方式解决：
Windows 版本为企业提供了 MSI 安装程序选项，专门用于解决此问题。管理员可以通过提要获取更新，以便他们可以根据需要审查和推出更新。
Chrome 的默认安装是用户绑定的，不能（也不会）影响其他用户或系统级项目，因此即使自动更新已启用，在最坏的情况下，也意味着清除用户的配置文件，在受控环境中，这通常归结为删除用户注册表和一些 AppData 等非关键内容。大多数企业将文档等存储在用户配置文件之外，并且重要的应用程序数据会复制并与服务器同步（即 CalDAV、IMAP、Exchange、PIM 和 Git 用于源代码等），因此影响相当小。
对于其他操作系统（macOS、Linux），安装也有两种选择（本地用户安装与系统安装），但对于系统安装管理，基于 Linux 和 macOS 的系统都有一套很好的工具来实现这一点，因为它们有基于包的安装程序，需要安装/更新/删除单个 .pkg/.deb/.rpm 或复制单个目录（即 .app 格式）。同样，设置和配置文件存储在用户主目录中，与用户的实际文件分开，因此即使出现最坏的情况，也与任何其他类型的配置文件问题相同：擦除配置文件，用户就可以恢复工作。
我确信有些应用程序不提供托管安装，只能使用自动更新，但我从未在任何企业环境中看到系统级和自动更新程序的组合是唯一的选择。如果您有想要销售的应用程序，至少提供一个打包/容器版本，可以作为具有用户级访问权限的单个项目添加或删除。这意味着它可以由用户和管理员管理。
最好的办法是拥有多个打包版本，这样您就可以为所有人提供服务。设置内部 CI/CD 来执行此操作通常只需要做一次，然后只需维护它以进行更改。当软件构建/编译等时，最后的打包步骤可以包括自动安装程序构建、打包构建、MSI 构建、PKG 构建等，您将能够以最低的成本为所有服务。
答案2
答案取决于您使用的平台提供哪些方法来更新软件。我的答案将针对我最了解的平台，即 Ubuntu 和 Fedora。它们分别使用 deb 和 rpm 软件包来安装软件和更新，deb 和 rpm 之间的差异在本问题的背景下并不大。
安装的文件大部分归 root 所有，安装程序需要以 root 身份运行才能拥有更新文件的权限。应用程序本身将以非特权用户身份运行，无法更新文件。如果应用程序尝试更新自身，则会失败。
应用程序可以通知用户有更新可用。但如果它想真正安装更新，它能做的最好的事情就是启动更新管理器，它会打开一个窗口提示用户输入必要的密码。
此时，自动更新将简化为打开更新管理器的快捷方式。因此，问题是您是否希望组织中的每个用户都拥有自己机器的管理权限。
推出更新的策略
在大型组织中，您可能希望首先只向少数用户推出更改，然后只要您没有听到用户的问题报告，就逐渐提高速度。
您需要根据更新的重要性来权衡这一点。如果它正在修复正在被积极利用的漏洞，或者如果该错误可能导致数据丢失或导致设备无法启动，您可能希望更新能够更快地推出。
我们必须考虑到这样的风险：从更新发布到系统管理员意识到有一个关键更新需要加快推出可能需要一些时间。
大型组织更有可能拥有足够的系统管理员，能够在短时间内评估每个软件更新并决定以多快的速度将其推广到所有机器。小型组织没有这些资源，可能必须足够信任软件供应商，才能开始推出软件更新，而无需进行手动审核步骤。