更新企业环境中的应用程序

Question

我对这个话题很陌生，希望有人能对此有所了解。我正在创建一个公司网络，它显然将有多个服务器和多个工作站。

比方说，Adobe的一个新版本问世了。我认为，在将更新“推送”到服务器和工作站之前，您应该在测试环境中测试此更新。

你们是如何控制、测试和推送应用程序更新的呢？(我不是在说windows更新)。你使用第三方系统管理工具吗？国产软件？

任何信息都将不胜感激:)

Answer 1

有一些工具可以在这方面提供帮助，如微软的SCCM、Active Directory软件部署、Altaris、LanDesk等。有100万零1种方法可以推送更新，但业务遵循最佳业务实践，并且不让用户管理员至少使用其中的一种。

至于测试，我通常首先将更新推到我自己的机器和一个小型测试实验室。戳几分钟，然后把它推到it部门的一个特定组，他们知道他们是我早期发布计划的一部分。然后，如果没有问题，我把它推给每个人。

Answer 2

微软的SCCM和其他各种产品将这样做。但是，它们让您完成特定的任务:安装软件。最大的问题是你如何协调这件事？

在“系统和网络管理的实践”一章中，有一章建议采用以下方法：

1. “一，一些，很多”--升级你自己的机器并测试几天。再升级几个(比如，您团队中的其他系统管理员)。然后推广到“很多”：越来越大的群体。
2. “金丝雀”--每个时间期升级一次，直到完成为止。
3. “指数”--升级1，然后再升级2，然后再升级4，然后再升级8。小组的规模每次都会翻倍。
4. “风险--不利的最后”--把组织分成几个小组，做最有风险的事情--首先接受风险，最后接受更多的风险。例如，可能有一组人以自己是最前沿而自豪，他们会自愿先走( IT部门，工程部门)。可能有一群人对升级非常怀疑，他们走最后一步(会计部、主管等)规模较小的群体也应该是第一位。

无论您如何分组升级，升级都应该首先进行测试，并且。

在每组升级之后，进行一系列测试。如果任何测试失败，或者报告了问题，请停止进行升级。如果可能的话，恢复到以前的版本(或安全版本)。

在您完成自己的测试之前，不应该启动升级。例如，在实验室或你自己的机器上。更多的结构化测试将包括在每种类型的机器上尝试升级，在操作系统的每一个版本上尝试升级，等等。测试应该包括启动和停止软件，以及运行其主要功能(因为您提到了Flash:尝试播放视频，运行闪存游戏，等等)。保留一个wiki页面是很好的，它记录了在哪里测试的组合以及您运行的测试。下次升级这个包时，您可以使用一个很好的测试列表。如果在升级期间报告了问题，请向列表中添加一个测试，以防止将来出现该问题。自从你提到Flash之后，我最近发现了一个问题，那就是Watcher的食物跟踪应用程序和一个特定版本的Flash。我们将该应用程序的URL添加到测试列表中，现在我们知道在发布之前必须对新的Flash升级进行测试。

在每组升级之间，暂停一段时间，看看是否会出现错误。这是一天还是一周取决于许多因素:这是一个巨大的变化吗？以前的组升级成功了吗？监视有关升级问题的报告。如果你有全职的服务台服务员，让他们知道什么升级正在进行中，所以他们是在寻找问题。

是否使用“一，一些，许多”或其他方法取决于许多因素。“一，一些，很多”在较小的环境中是好的。“指数”是一个很好的大型桌面环境，数百台机器都是集中控制的。“最后的风险广告”是好的，当你可以把你的用户分成不同的“个性”的特定组。“金丝雀”用于网络农场和网格计算，在那里您有数百或数千台机器，所有的配置都是相同的。

最重要的是做好笔记。如果你必须做一个好的升级一次，你将不得不做更多的升级在未来。您希望过程变得可重复，并且保持一个测试执行列表是关键。下次你做类似的升级时，你需要做的想法就会减少，这意味着错误会减少(“哎呀，我忘了测试废话了”)，它会更快。事实上，如果您只保留基本文档，那么您可以将其委托给您雇用的新的初级系统管理员。他或她可以重复你的过程，增加它，并改进它。你可以集中精力训练他们，检查他们的工作。同时，您也可以从事其他项目。

Answer 3

如果您正在寻找一个用于脚本系统升级和管理不同配置文件的轻量级工具，请查看wpkg。它只为您提供了一个框架，但最后您必须自己找出升级/静默安装/卸载语法。

一旦你有了它，你就可以有很少的虚拟机--测试组的成员--在测试新版本之前，让所有用户都可以使用它们。

像忍者、前应用程序或wpkg.org这样的站点可以是不同软件无人参与的安装方法的来源。