我对这个主题很陌生，希望有人能对此有所启发。我正在创建一个显然会有多台服务器和多台工作站的企业网络。
假设 Adobe Flash 发布了新版本。我认为，在将其“推送”到服务器和工作站之前，您需要在测试环境中测试此更新。
你们如何控制、测试并推出应用程序更新？（我说的不是 Windows 更新）。你们使用第三方系统管理工具吗？自制软件吗？
如有任何信息我们将不胜感激:)
答案1
有一些工具可以协助实现这一点，例如 Microsoft 的 SCCM、Active Directory 软件部署、Altaris、LanDesk 等。有无数种方法可以推出更新，但遵循最佳业务实践并且不让用户管理员使用其中至少一种的方法。
至于测试，我通常会先将更新推送到我自己的机器和一个小型测试实验室。四处查看几分钟，然后将其推送给 IT 部门内知道他们属于我早期发布计划的一部分的选定小组。然后，如果没有问题，我会将其推送给所有人。
答案2
Microsoft 的 SCCM 和其他各种产品都可以做到这一点。但是，它们会让您执行特定任务：安装软件。最大的问题是如何协调这一点？
在《系统和网络管理实践》中有一章推荐了以下方法：
“一个、一些、许多”——升级您自己的机器并测试几天。再升级几个（例如，您团队中的其他系统管理员）。然后推广到“许多”：越来越大的群体。
“canary”——每隔[一段时间]升级一个，直到完成。
“指数”——升级 1，然后再升级 2，然后再升级 4，然后再升级 8。每次升级时，组大小都会翻倍。
“风险规避最后”——将组织分成几组，风险承受能力最强的先做，风险规避能力最强的最后做。例如，可能有一个小组以自己处于前沿而自豪，并自愿首先做（IT 部门、工程部门）。可能有一个小组对升级非常怀疑，他们最后做（会计部门、高管等）。较小的小组可能也应该先做。
无论你如何对升级进行分组，都应首先对升级进行测试，然后。
每“组”升级完成后，进行一系列测试。如果任何测试失败，或者报告了问题，则停止升级。如果可能（或安全），则恢复到上一个版本。
升级应该在您完成自己的测试之前开始。例如，在实验室或您自己的机器上。更结构化的测试将包括在每种机器、每个操作系统版本等上尝试升级。测试应包括启动和停止软件，以及运行其主要功能（因为您提到了 Flash：尝试播放视频、运行 Flash 游戏等）。最好保留一个 wiki 页面，记录测试了哪些组合以及您运行了哪些测试。下次升级此软件包时，您将有一个很好的测试列表可供使用。如果在升级过程中报告了问题，请将测试添加到列表中以防止将来出现该问题。由于您提到了 Flash，我最近发现 Weight Watcher 的食物跟踪器应用程序和某个版本的 Flash 存在问题。我们将该应用程序的 URL 添加到测试列表中，现在我们知道在发布新的 Flash 升级之前必须使用该应用程序进行测试。
在每“组”升级之间，暂停一段时间以查看是否出现错误。这到底是一天还是一周取决于许多因素：这是一个大变化吗？之前的组升级是否成功？监控您的帮助台票证以获取与升级相关的问题报告。如果您有全职帮助台工作人员，请让他们了解正在进行的升级，以便他们留意问题。
是否使用“一、一些、许多”或其他方法取决于许多因素。“一、一些、许多”适用于较小的环境。“指数”适用于大型桌面环境，其中数百台机器由中央控制。“风险警告最后”适用于您可以将用户划分为具有不同“个性”的特定组。“金丝雀”用于 Web 农场和网格计算，其中您拥有数百或数千台具有相同配置的机器。
最重要的是做好笔记。如果你曾经做过一次很好的升级，那么将来你就会做更多的升级。你希望这个过程是可重复的，而保留一份已执行的测试列表是关键。下次你做类似的升级时，你不需要再思考，这意味着更少的错误（“哎呀，我忘了测试等等”），而且升级速度会更快。事实上，如果你只保留基本的文档，那么你可以把这件事委托给你雇佣的新初级系统管理员。他或她可以重复你的流程，添加内容并改进它。你可以专注于培训他们并检查他们的工作。同时你可以从事其他项目。