为您的应用程序配备万无一失的部署能力：与 Tom Spalthoff 的对话
公司可以实现可靠的桌面环境，同时减少准备高质量应用程序包所花费的时间和成本。
Queue： 您好，这里是 cast Premium Edition 的另一期节目，主持人 Mike Vizard。今天加入我的是 Tom Spalthoff，他是 Macrovision 公司的系统工程师，该公司是领先的应用程序打包解决方案提供商。Tom，欢迎来到节目。
Spalthoff： 谢谢，Mike。
Queue： 人们在分发应用程序以进行实际部署时，遇到的根本问题是什么？因为我们花费了大量时间专注于构建应用程序，然而似乎最让人头疼的是应用程序实际推出和部署的时候。
Spalthoff： 当然，我的意思是，使用当今市场上的自动化部署解决方案（如 SMS、Zenworks、Landesk 和 Tivoli 等）是很棒的，但人们往往不够重视的是，我必须确保我部署的东西能够正常工作，并且在安装到这些桌面上后不会引起问题。因此，当您按下按钮一次性部署到数百或数千个工作站时，要有信心应用程序已经过测试，不会让您陷入 DLL 地狱，也不会与这些机器上已有的其他应用程序冲突。
因此，关键在于这些软件包的定制和测试。
Queue： 那么，为什么我们没有进行足够的测试呢？这只是流程中被忽视的一部分吗？或者，流程的结构方式是否有什么地方促使我们忽视流程的这一部分？
Spalthoff： 嗯，这很难，对吧？ 关键在于，要针对您的所有基线映像以及它们可能共存的所有应用程序准确地测试一个新的应用程序，这变成了一个非常困难的问题，而利用 Windows Installer 技术和微软在 MSI 领域的工作，这本身是有道理的，但通过这样做，安装的细节被公开了。它们存储在 MSI 的表格中，并且通过像 Macrovision 的 Admin Studio 这样的解决方案，我们可以将这些细节加载到一个中央存储库中——我们称之为应用程序目录——这有助于测试。
现在我知道了关于安装将要做的一切，它将要放置的文件，注册表设置——所有这些东西——我可以基本上运行查询，看看如果我将刚刚获得的这个新应用程序与这个基线映像、这些补丁、这些其他应用程序一起放置，会发生什么？ 它会覆盖东西吗？ 会与东西冲突吗？
然后是更基本的测试内容：它是否是一个格式良好的 MSI，我们是否通过了微软的验证规则，它是否为 Vista 准备就绪？ 我是否有任何关于不在桌面上放置图标或不在启动菜单中放置东西的企业标准？ 我可以测试所有这些东西，以便当我按下按钮将文件分发到桌面或工作站上的应用程序时，我有信心它会按照我的预期工作，并且会看起来像我想要的那样。
Queue： 我想知道流程中是否存在根本性的错误，因为一方面我们有花费所有时间构建应用程序的应用程序开发人员。然后我们有另一组人，我想我们称之为安装作者，他们实际管理应用程序的部署，他们有点在不同的环境中工作，并且彼此之间没有太多沟通。
Spalthoff： 是的。 我的意思是，这当然是等式的一半，特别是在金融机构中，我们看到大量的内部开发的应用程序占据桌面，金融机构可能管理的应用程序中有多达 50% 是内部开发的。
其他组织可能会看到这个数字变得更小，并且他们主要处理商业应用程序。
但是，使用像 InstallShield 这样的工具（它成为 Admin Studio 的一部分），您可以使用它们的向导来获取项目、开发项目，并将它们直接构建到 MSI 中。 最糟糕的事情莫过于一个内部小组开发一个应用程序，他们认为他们是在帮你的忙，为你创建了一个漂亮的安装程序，然后你不得不回去重新打包，因为你不知道它包含什么，你不知道它会做什么，而且在首先了解这些东西之前，你根本无法发布它。
因此，是的，利用一些工具来自动构建 MSI，然后将其输入到您的测试流程中，与您的其余 MSI 和应用程序一起，通常是一个更精简的流程，并且将更快地发布这些应用程序。
Queue： 制定一套用于测试的标准工具是否有价值主张？ 这有助于弥合这种分歧吗？
Spalthoff： 是的。 我们通常看到的是，要么测试过程被绕过：“嘿，我们只是没有时间”，“我们没有奢侈到重新映像工作站并加载应用程序并在周日进行六种方式的测试。” 因此，要么根本没有完成，这更像是手榴弹方法：让我把它扔出去，希望帮助台准备好处理所有可能打来的电话。
或者，您必须利用一些自动化工具，比如我们提供的工具，以便实时进行测试，并且仍然满足您对最终客户的承诺、服务级别协议和类似的东西。
但是你也说了一些有趣的事情。 流程变得至关重要，特别是随着打包团队的壮大，你有不止一两个人做这件事，你如何沟通你正在做什么，它在流程中的位置，你如何将这些信息反馈给那些请求这些东西的人变得越来越重要，我们看到人们使用像我们的工作流程管理器工具这样的解决方案，该工具与打包工具集成，并允许您将您的流程制度化到工具中，这样当您引入新的打包人员时，当您可能引入顾问或承包商来做打包工作时，您真的可以规定他们将要经历的流程，这样，无论是由 Jane、Joe、Ginny 还是 Jim 进行打包，您都有信心后端出来的东西将以相同的方式构建，它将以相同的方式进行测试，然后它将以您期望的方式运行。
Queue： 您提到了手榴弹方法，我想也许在 10 年前，您可能还能侥幸逃脱，但我目前的印象是，感觉好像有一个“每日补丁”，每周都有更新，需要推出，因为存在一些安全问题，您再也不能侥幸逃脱推出手榴弹了。
Spalthoff： 嗯，你只是不能冒险，对吧？ 随着现在生效的合规性规则，您不能不知道安装程序在到达机器后会对机器做什么。 您必须知道它将要放置哪些文件。 您必须知道它可能会打开哪些潜在的漏洞。 因此，我们在我们的补丁影响管理器工具中也看到了这一点，即，嘿，如果我可以获得这些微软补丁的详细信息，我可以将它们加载到中央存储库中，其中包含关于我的基线操作系统和我的所有应用程序的信息，我可以非常确定地知道这些补丁将产生什么样的影响，这样，如果它不会对我的环境造成严重破坏，我可以尽快发布它，如果它确实会影响某些东西，至少我知道这些影响在哪里，我可以集中我的测试。
对于补丁，我们看到了同样的事情，大多数人得到的是——补丁星期二到了，他们从微软那里获得了信息。 他们在周六晚上有一个维护窗口，他们有三天的时间进行测试。 他们在那个时间内尽可能多地进行测试，并且他们抱最好的希望，并且使用像我们的工具这样的工具，您可以更有信心地认为您没有投掷手榴弹，而是实际上在推出这些补丁时准确地执行您想要执行的操作，这使您的环境更安全。
Queue： 是的，除了安全风险之外，帮助台再也无法忍受那种滥用。 一旦出现问题，他们就会开始大声疾呼应用程序存在问题。 他们不区分部署方法的问题和应用程序的问题。 他们只是说应用程序坏了。
Spalthoff： 嗯，是的，界限变得非常模糊，对吧？ 那么哪里出错了。 是部署工具做了坏事还是——所以你是对的。 提高这种信心使每个人的生活都轻松一点，因为对于一个 IT 团队来说，有比跑到桌面并试图修复可能通过更好的测试来预防的问题更好的事情要做。
Queue： 如果人们没有像您这样的测试工具，他们今天如何解决这些问题？ 他们是否在进行大量的单独测试，这更像是一种碰运气的方法？ 我想我的问题是，如果您采用这种方法，当您谈论数百甚至数千个应用程序时，您如何扩展？
Spalthoff： 是的。 这非常困难。 我们通常听到的是，人们会——他们有一个 ghost 映像，其中包含他们的基本操作系统和他们的核心应用程序，如果他们获得一个新的应用程序，他们会 ghost 这台机器，然后加载它，看看会发生什么，如果一切看起来正常，也许他们会抓取另一个基线操作系统并在其上尝试。
通常，然后他们会进行试点。 因此，他们会将其发送给少数人，如果一切顺利，那么他们会扩大范围。
但是最终，最终的结果是，做所有这些事情花费的时间越来越长。 因此，对于这些内部团队来说，这是一个棘手的公共关系问题，因为人们或好或坏地说，看，我在家拿到一张 CD。 我将其加载到我的机器上，它就可以工作了。 只需 10 分钟我就完成了。 为什么当我获得新的应用程序升级或新的补丁或需要加载到我的机器上的东西时，在我可以将它加载到我的桌面上之前需要两周的时间？
因此，在您可以在尽可能短的时间内缩短该周期并进行尽可能多的测试的范围内，人们就越快乐，并且最终，您需要的打包团队就越小，并且通过使用自动化工具，这些规模经济在员工生产力和您的 IT 团队中都得到了回报，而且在您支持的应用程序和桌面的正常运行时间增加方面也得到了回报。
Queue： 还有一种新的趋势，人们正在谈论需要围绕迭代开发建立一个基于 Web 的模型，我几乎每月或每季度都会发送新功能，几乎就像软件即服务模型一样，而不是进行一次全面的“这是我的应用程序升级”，我每 18 个月做一次，这意味着测试周期必须是持续的，对吧？
Spalthoff： 是的。 这些是一次性交易的想法是错误的。 您必须做好准备，并且您必须建立一个可靠的流程，您期望这些更新会到来，无论是每月、每季度还是每年，无论是什么，它们都会到来，并且不会中断您的工作流程和日常运营，只需让它通过一个规定的流程即可。
如果应用程序供应商正在生成 MSI，即使是每月，也要加载它，针对它运行一系列自动化测试，然后能够部署它，如果您使用自动化，那不是一个繁重的过程。 如果您手动执行这些操作，并且测试它需要一周的时间，然后您在下一个版本发布之前只有三周的时间，那么现在您就遇到了严重的生产力问题。
Queue： 那么您的工具实际上是如何进行测试的？流程是什么？测试某些东西实际需要多长时间？ 这取决于应用程序的大小还是什么？
Spalthoff： 有几个变量，但时间是以分钟和小时来衡量的，而不是以天和周来衡量的。 对于一个规模适中的企业来说，典型的测试场景通常包括重新打包。 如果它仍然是一个遗留应用程序，它不是 MSI，您需要将其转换为 MSI 格式。 因此，我们提供重新打包工具，该工具基本上可以完成转换。
一旦它进入 MSI，企业内部通常会有标准，即，看，这就是我们希望在“添加删除程序”中显示的样子，不希望在启动菜单上有任何东西，我们不想要桌面图标，我们不想要快速启动按钮——我们不想要任何这些东西。
因此，我们将建立标准和模板，并将它们应用于我们将要部署的每个应用程序。 因此，通常，会进行一些自定义。 然后，一旦像这样设置好，MSI 通常会被加载到我们的应用程序目录中，以便可以针对它运行验证规则。 这是一个格式良好的 MSI，符合 Microsoft 建立的标准集，我们将针对我们的冲突分析运行它，以便我们可以说，嘿，如果这个应用程序与桌面上的应用程序共存，它可能会与哪些应用程序冲突？
然后，我们有多种方法可以补救这些冲突，从而避免问题的存在。
从那里，我们还有其他几个测试工具来执行锁定测试、Vista 准备就绪测试以及检查文件关联是否正常工作。
更好的是，通过我们的一些自动化工具和我们的软件包专家功能，您能够自动化这些东西，并说，看，这是我想对任何通过这里的应用程序运行的一系列测试，并发布结果。 在许多情况下，如果 MSI 存在常见问题，我们可以自动修复它们。
因此，您可能有 80 个问题或 80 个问题，其中 77 个可以自动解决，这使您可以将您的补救工作重点放在剩余的三个问题上。
因此，归根结底，我们将自动化您在干净的机器上或在您的基线操作系统上加载应用程序所做的几乎所有事情，并将结果与应用程序一起保存在应用程序目录中，因此您有一个很好的历史记录，一个审计跟踪，记录发生了什么，更改了什么，为什么更改，谁进行了更改，以及所有这些东西。
因此，该过程在某种程度上取决于有多少应用程序。 如果您针对几十个应用程序进行测试，它会比针对几千个应用程序进行测试运行得更快，但您仍然在谈论运行几分钟和可能几小时的过程，而不是几天和几周。
Queue： 您提到了 Vista。 因此，我想现在是提出我们正在看到的即将到来的转变的好时机，即从 Windows XP 迁移到 Vista。
从测试的角度来看，在 Vista 环境中推出应用程序是否有任何独特之处是人们应该注意的？
Spalthoff： 嗯，您需要注意的更重要的事情之一是用户访问控制。 他们为每个用户在机器上可以拥有的权限添加了额外的粒度。 因此，它为管理员提供了大量关于如何锁定机器的功能。 他们有——不仅仅是开/关，它是锁定的还是未锁定的？ 所以你有不同的级别在里面。
因此，您确实需要注意应用程序如何与用户访问控制交互。 Vista 中的重启管理器功能还为您提供了一些功能，可以防止您在安装应用程序时必须重启工作站。
因此，检查这些东西并利用这些东西通常是您要在重新打包过程中做的事情。 使用我们的工具，我们有一系列测试要运行，如果它要尝试重启，我们会标记出一些东西，我们可以做一些更改来使用重启管理器，并且不会发生这种情况吗？
如果权限和访问控制方面存在问题，我们可以在您实际部署之前而不是之后标记出这些问题。
更好的是，当我们与人们交谈时，我们听到各种各样的说法，从“是的，我们将尽快迁移到 Vista。 对吧？ ‘今年夏天，我们将开始推出 Vista’”到“是的，也许在几年后的某一天，我们将这样做。”
但是，如果您正在使用这些类型的工具，现在为 Vista 准备好您的应用程序可能只是您经历的过程的一部分，这样当上面有人说，好的，现在是迁移到 Vista 的时候了，至少您管理的应用程序组合可以为此做好准备，这样将所有这些应用程序从 XP 迁移到 Vista 就不是一项大规模的工程。
您可以说，作为我们打包过程的一部分，我们一直在确保，随着应用程序的新更新的到来，我们现在为 Vista 做好准备。
Queue： 支持混合 Vista Windows XP 环境是否会面临挑战？ 因为我不认为我认识任何人会一夜之间全部迁移到 Vista。
Spalthoff： 你知道这类似于人们迁移到 XP 的时候。 相同的迁移计划。 当人们从 2000 迁移到 XP 时，我们听到的与我们期望人们迁移到 Vista 时听到的是一样的，这将是一个漫长的过程，这就是为什么将您的测试计划以及您的不同基线操作系统加载到应用程序目录中以便您可以针对所有这些环境进行测试将为您节省大量时间。
如果您考虑一个您确实拥有多个操作系统和组织内不同组的多个基线的环境，如果您尝试手动执行，则测试过程可能会非常繁琐。
Queue： 最后一个问题，Tom。 当人们接近整个测试过程并考虑如何实际最大限度地降低他们的成本、安全风险以及他们自己必须投入到项目中的时间量时，您最好的建议是什么？
Spalthoff： 嗯，我建议从关注流程开始。 今天肯定有很多关于如何准备应用程序以进行部署的可用资源。 微软的业务桌面部署资料及其解决方案加速器计划在建立一些关于此处是您需要做的事情以准备应用程序进行部署的基线方面大有帮助。 因此，请查看该资料，然后尽可能多地自动化。 有可用的工具来采用其中的一些测试平台，以便您可以尽可能快地完成测试，并且您不必在部署之前跳过该步骤。
因此，关注流程，使其可重复、可衡量，当您意识到您的员工有太多的工作要做时，您可以使用指标来指出并说，是的，我们需要增加员工，或者我们有多余的员工名额。 至少您有一些可以指出的硬性数字，然后让技术尽可能地完成繁重的工作。
自动化测试，确保您有一个中央存储库来存储所有要测试的应用程序，当然，始终使用 MSI。
Queue： 这是 cast 的另一期节目，主持人是 Mike Vizard。 本期节目由领先的应用程序打包解决方案提供商 Macrovision 赞助。 请访问 www.Macrovision.com 了解更多信息，Tom，我想感谢您参加节目！
Spalthoff： 我的荣幸，Mike，感谢邀请我们。
最初发表于 Queue 第 5 卷，第 2 期—
在 数字图书馆 中评论本文
更多相关文章
- 从负债到优势：与 John Graham-Cumming 和 John Ousterhout 的对话
软件生产（软件开发的后端，包括构建、测试、打包和部署等任务）已成为许多开发组织的瓶颈。 在本次访谈中，Electric Cloud 创始人 John Ousterhout 解释了如何将软件生产从负债转变为竞争优势。
Martin J. Steinmann - 使用 SIP 的统一通信
基于 SIP（会话发起协议）标准的通信系统在过去几年中取得了长足的进步。 SIP 现在基本上已经完成，甚至涵盖了高级电话和多媒体功能以及功能交互。 不同供应商的解决方案之间的互操作性在 SIP 论坛组织的 SIPit（互操作性测试）会议等活动中得到了反复证明，并且一些制造商已经证明，对该标准的专有扩展不再是由技术需求驱动，而是由商业考虑驱动。
Jason Fischl, Hannes Tschofenig - 让 SIP 更划算
会话发起协议 (SIP) 用于在基于 IP 的网络中建立实时会话。 这些会话可能是用于音频、视频或 IM 通信，或者它们可能用于中继状态信息。 SIP 服务提供商主要专注于提供一种服务，该服务复制 PSTN（公共交换电话网络）或 PLMN（公共陆地移动网络）提供给基于 Internet 的环境的服务。
David A. Bryan, Bruce B. Lowekamp - 去中心化 SIP
SIP（会话发起协议）是当今使用的最流行的 VoIP 协议。1 它被企业、消费者甚至运营商广泛用于其网络核心中。 由于 SIP 旨在建立任何类型的媒体会话，因此它也用于 VoIP 以外的各种多媒体应用，包括 IPTV、视频会议，甚至协作视频游戏。
© 保留所有权利。