我们的客户的解决方案包括多个相互协作的产品。当我们更新解决方案的任何部分时，我们必须为每个操作系统（XP、Windows 7、Windows Server 2008 等）提供管理员指南。指南告诉您：
- 更新前应停止哪些服务和进程
- 应该备份哪些文件
- 应更新哪些配置键
- 应该卸载哪些程序/模块
- 应该安装哪些程序/模块
- 如何检查更新是否成功
- 恢复步骤
- ETC
基本上，我们将安装文件放在网络文件夹中，并提供应在客户希望更新的工作站上运行的 powershell 脚本。此脚本可能相当复杂，并且可能因安装不同而发生巨大变化。
我想有没有什么平台可以简化这种分发？
答案1
没有任何“灵丹妙药”可以帮你解决这类问题。如果有人告诉你有灵丹妙药，我会持怀疑态度。
我曾经使用过签入 VCS 的构建脚本，所以我的偏见可能会在这里显示出来。
我将讨论其他人提到的几个问题：
乍一看，Windows Installer 确实很有吸引力，但它并不是“免费午餐”。如果您选择构建 Windows Installer 软件包，则只需将脚本中的依赖项和逻辑封装到安装程序包中，可能还会包含大量不美观的内容，例如大量的自定义操作。实际上，您将使用 Windows Installer 作为脚本环境，其中包含许多内置的怪癖和限制。
如果你使用配置管理系统（Desired State Configuration、Puppet 等），那么仍然必须对依赖关系和逻辑进行建模。我敢说，使用配置管理系统时，您会遇到平台描述依赖关系的能力限制，此时您无论如何都需要使用脚本进行补充。
我认为你的 Powershell 脚本已经走上了正确的道路。我会对脚本进行注释，然后就可以了非常很难构建一个可以处理所有各种安装场景的单个脚本（或者更可能是从单个中心脚本调用的一组较小的脚本）。我会使用版本控制软件来维护这些脚本。只要对于您从不透明二进制 blob 安装的产品是可行的，我就会构建测试逻辑来验证这些安装程序是否真正有效。
答案2
使用标准安装程序 (.msi)，这可以解决大多数问题。请查看威克斯为开源平台构建安装程序。
答案3
您可能想看看 Puppet。我曾用它来管理基于 Unix 的计算机的配置，但它也适用于 Windows 操作系统。