在公司环境中更新应用程序

像微软的SCCM，活动目录软件部署，Altaris，LanDesk等有一些工具可以帮助你。有一百万种方法推出更新，但是遵循最佳商业惯例并且不让他们的用户pipe理员使用的业务至less有一个。

至于testing，我通常会把更新推到我自己的机器和一个小testing实验室。 打了几分钟，然后把它推到IT部门的一个精选小组，知道他们是我的早期发布时间表的一部分。 那么，如果没有问题，我把它推给大家。

微软的SCCM和其他各种产品将会这样做。 但是，他们让您执行特定的任务：安装软件。 最大的问题是你如何协调这一点？

在“系统和networkingpipe理的实践”中，有一章介绍了以下方法：

1. “一，一些，很多” – 升级你自己的机器并testing几天。 升级一些（比如说你的团队中的其他系统pipe理员）。 然后推出“许多”：更大和更大的群体。

2. “金丝雀” – 每隔一段时间升级一次，直到完成。

3. “指数” – 升级1，然后2更多，然后4更多，然后8更多。 团队规模每增加一倍。

4. “最后的风险 – 不利的风险” – 将组织分成小组，首先承受风险最大，风险最不利的最后。 例如，可能有一个组织以自己为先锋，自愿先走（IT部门，工程部门）。 可能有一个组织对升级非常怀疑，他们走到最后（会计部门，高级pipe理人员等）。小团队也许应该先走。

不pipe你如何对升级进行分组，升级都应该先testing一下。

在每个“组”升级之后，进行一系列testing。 如果有任何testing失败，或者报告有问题，请停止升级。 如果可能（或安全）恢复到以前的版本。

在你完成自己的testing之前，升级不应该开始。 例如，在实验室或您自己的机器上。 更多结构化的testing将包括在每种机器之一上尝试升级，每个版本的操作系统之一，等等。 testing应该包括启动和停止软件，以及运行其主要function（因为你提到的Flash：尝试播放video，运行Flash游戏，等等）。 保持一个维基页面是很好的，它logging了什么样的testing组合以及你运行的testing。 下一次你升级这个软件包时，你有一个很好的testing列表。 如果在升级过程中报告了问题，请将testing添加到列表中以防止将来出现此问题。 自从您提到Flash以来，我最近发现Weight Watcher的食品跟踪器应用程序和某个版本的Flash存在问题。 我们将该应用程序的URL添加到testing列表，现在我们知道新的Flash升级必须在我们发布之前进行testing。

在每个“组”升级之间，暂停一段时间以查看是否出现错误。 这是一天还是一周，取决于很多因素：这是一个很大的变化吗？ 以前的组升级成功了吗？ 监视您的服务台门票以获取与升级相关的问题报告。 如果你有全职的服务台助理，让他们知道正在进行什么升级，所以他们正在寻找问题。

无论您使用“一个，一个，多个”还是其他方法，取决于许多因素。 “一个，一些，很多”在较小的环境中是好的。 “指数型”在有数百台机器集中控制的大型桌面环境中很好。 当您可以将您的用户划分为具有不同“个性”的特定组时，“风险 – 最后一个”是很好的。 在networking农场和网格计算中使用“Canary”，其中有数百或数千台机器都具有相同的configuration。

最重要的是要记笔记。 如果你不得不一次做一次好的升级，将来你将不得不做更多的升级。 你希望这个过程变得可重复，保持一个testing列表是关键。 下一次你做类似的升级时，你会有更less的想法，这意味着更less的错误（“哎呀，我忘了testing等等），它会更快。 事实上，如果你只是保持基本的文档，那么你可以委托给你雇用的新的，初级的，系统pipe理员。 他或她可以重复你的过程，添加并改进它。 您可以专注于培训他们并检查他们的工作。 同时你可以在其他项目上工作。

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

一旦你有了它，你可以有几个虚拟机 – 一个testing组的成员 – 在testing新版本之前，所有的用户都可以使用它们。

像itninja [原appdeploy]或wpkg.org这样的网站可以成为不同软件的无人值守安装食谱的来源。