面向软件开发周期的虚拟化模式

在软件开发周期中，除了支持单纯的软件开发流程之外，虚拟化技术还可为众多要点带来重大的工作效率提升。

作者：Andrew Binstock

软件开发周期（SDLC）之所以能提供为广大开发人员提供众多机遇，其中虚拟化技术的作用功不可没。在几乎所有类似的情况中，虚拟化带来的优势是其它技术都难以复制的。为此，虚拟化在企业 IT 软件开发部门中的采用率相当高。本文为您重点剖析了扩展的 SDLC 中的创新使用案例，并和您探讨虚拟化能够以怎样的方式带来全新甚至是意外的优势。

在我即将讨论的场景中，虚拟化技术的两项重要属性将起到主导作用：虚拟机（VM）不仅易于复制，而且成本较低，可以随时丢弃。虚拟机以简单文件的形式存在，通常包括两个文件：一个小型配置文件，另一个是用于模拟虚拟机磁盘的超大文件。当虚拟机启动时，它首先会检查配置文件，然后从模拟磁盘中读取数据，其中包括保存所有虚拟机操作系统软件和应用的模拟文件系统。在虚拟机运行过程中，它写入本地磁盘的任何数据都将写入这个文件中（显然不包括联网驱动器，因为它们并不被视为是本地驱动器）。因此，您可以在虚拟机不运行的时候，通过简单复制配置和磁盘文件来克隆虚拟机，从而完全复制虚拟机的状态。

运行克隆版本时，应该牢记以下几点。首先，如果不进行人工干预的话，克隆版本不能与原虚拟机同时运行于同一网络。这是因为：原始版本和克隆版本拥有相同的 IP 地址和 MAC 地址，这样就会在第二台虚拟机运行时造成严重的破坏。通过使用实验室管理器软件（如 VMware 的 VMware Lab Manager 或 Surgient 的VQMS）或手动修改数值可解决此类问题。其次，如果克隆虚拟机运行于不同的系统上，配置文件可能需要做出相应更改。该文件将指明虚拟机硬盘文件的位置，因此，如果后面的文件进行了重新定位，那么配置必须更新。除上述两个问题之外，保存、克隆和运行一台虚拟机上的多个例程都非常简单。（在大多数情况下，操作系统和应用的授权限制仍然有效。）

如今，如果不在网络上花费大量时间，进行项目研究将会难上加难。基于 Web 的研究可用于要求收集、工具评估、设计、资源定位（如开放源代码产品或代码片断）以及类似工作。这种研究的棘手之处在于（尤其是涉及到反复查找（spidering）的工作）恶意网站可能潜伏在貌似实用的网站之中。现在，恶意站点总是尝试感染只是访问主页的系统，因此任何类型的搜索自动化都危机四伏。

保护站点免受恶意软件攻击的方式之一即是从虚拟机内部进行 Web 搜索。如果虚拟机被感染，您只需将其丢弃，换上一份未感染的原始虚拟机副本，即可继续搜索。由于 Web 搜索中的所有写入动作都应该在虚拟机的本地磁盘上完成，所有病毒、rootkit 及其它恶意数据包都将被写入虚拟机的单一虚拟化硬盘，因此感染也将遏制在该单一文件中。当然，如果您从虚拟机中运行病毒，那么您也有可能将病毒扩散到网络上的其它系统。但是，即使如此，您也还是可以控制：只需允许特定流量进出虚拟机即可。此外，Cookie 和密码管理也对此类保护提出了几项管理问题，但是这些问题的解决方法相当直接，远比当 Web 受到（可避免的）感染时从头开始重新构建开发人员的工作站要简单得多，可有效帮助您快速解决难题。

许多大型项目都涉及到一些评估工作：例如，开发人员工具、同类解决方案、可能使用到的组件，以及开放源代码解决方案等。我在本站点的一篇配套文章  中讨论了在评估开发人员工具中使用虚拟化的问题。评估同类产品（对 ISV 而言尤为如此）是要求收集工作中的重要一步。为了评估同类产品，您需要大量使用虚拟机。其中一个首要原因就是：您希望在一个空白系统上安装同类软件，以便确保标准的常用评估环境。从某种程度上讲，该虚拟机就是一个控制环境。一旦您载入软件并在虚拟机中运行，请务必复制虚拟机。这种克隆可支持您在每次安装软件时随时重新创建新的副本。这是一个分类备份选择，可支持您对现有评估虚拟机上的配置和选项进行任意设置。

如果您发现 bug 或问题并希望通知整个团队，您可以保存发生问题的虚拟机，并通过电子邮件通知团队成员运行该虚拟机并查找问题。为了避免团队成员在查看虚拟机时更改错误条件，您可以在通知他们之前单独保留一份副本。

这样，您便可以构建一系列着重反映同类产品各种难点（及其强项）的虚拟机。这些简洁对比应保存在分类库中，以便日后进行检查，并作为可链接的标志用于确定具体的产品要求。这样使用，虚拟机库还可为 QA 工程师提供功能性测试信息，供其复制同类产品的缺陷，并确保它们不会出现在当前的产品中。

虽然虚拟机库要占用很大空间，但即使在产品推出后也应该加以保留，因为其他部门的团队可能用它开展实地工作。例如，销售团队在设计展示同类产品缺陷的幻灯时可能可能会用到虚拟机。

现在，许多项目都需要具有多学科技能的团队。通常，有一技之长的工程师只使用专为其领域设计的工具，这也正是新近在应用周期管理厂商中兴起的“全新基于角色的工具”的基本逻辑。一些产品已经超越了基于角色的定义，开始使用个性化概念。一种改进基于角色的工具的上佳方法就是为开发人员提供协助工作的虚拟机。这种虚拟机具有特定的工具配置，随后可载入开发人员的工作站中。鉴于当今平台的运行速度较快、大多数虚拟化软件成本较低，完全借助虚拟机工作的开发人员将迅速忽略掉“台式机已实现虚拟化”这一事实。同时，站点还能通过对特定用户发放昂贵的授权来限制用户对工具进行访问。此外，管理员还可确保开发人员正在使用经过验证的工具、平台和配置，有力保障工作的顺利运行。

虽然所有的开发人员都拥有相同的责任，但是仍然不乏一些高级开发人员或者小型站点的工作人员对此特性产生抵触。但是，即使在这样的环境中，这种运行于虚拟机的指定环境的方法也支持两组特定用户：新员工和实习生，以及海外开发人员。对于后者来说，这是一个非常好的方法（尤其是在您很难管理团队成员时），因为您能够通过使用虚拟机来确保使用合适的工具、库及其它配件。

我在前面提到的文章中为大家解释了虚拟机如何对写入软件的目标平台进行标准化。在许多站点上，开发人员工作站通常不包括在专为个人笔记本电脑设计的平台配置中。对于某一开发站点，要想确定是否在用户环境的真正例程上测试新代码，它就应该保留具备所有经过验证的用户系统资料的虚拟机库，并在每次进行用户测试时克隆一份资料副本。由于虚拟机的成本较低，可以随意克隆和丢弃，所以站点应该确保每次测试均采用新的虚拟机，而不是先前测试修改过的虚拟机。

SDLC 定义通常将应用支持作为最后一步（维护）的重要组成部分。无论 SDLC 方法在您的站点中发挥何种作用，很显然前线员工不能解决的支持问题总是被退回给开发人员。因此，无论如何，如果支持人员没有所需的工具，仍然需要开发人员的帮助。

解决上述问题的一种新方法就是为员工提供虚拟机库，其中已将软件预安装在各种被正式批准的平台上。如果支持工程师不能立即解决求助电话中的问题，他们可以调出所需的虚拟机，对其进行配置以模拟用户的环境。例如，如果用户正在通过运行于 Windows 2003 Server 上的一个 JBoss 例程，运行一个接入 MySQL 数据库（运行于 Linux 版本上）的 Microsoft Windows 2000 Workstation 客户端，那么帮助中心员工就可将这些虚拟机从库中调出，并放入虚拟机主机上的单一配置中，即可拥有与用户咨询问题相同的环境。由于此类安排的设置速度非常快，（用户的电话还没挂），因此用户和帮助中心员工可以更方便地讨论相同的问题，共同寻求解决方案。在很多情况下，这一步骤均可有效避免支持人员进行不必要的现场维修。

如果用户遇到了罕见的问题，应将整个支持虚拟机库存档。随后，用户可向开发团队发送一个链接，开发人员便能够亲眼看到问题并进行层层分析，从而找到症结，快速解决问题。

同样，如果用户的问题没有完全解决，帮助中心员工也可以再次利用存档的虚拟机库：如果用户再次打来电话，工作人员就可以下载保存的虚拟机，并接着上次的对话继续讨论对策。

在本文中，我们主要探讨了 SDLC 引发的相关使用案例，并没有关注单纯的软件开发活动。对于开发的具体流程以及能够从虚拟化中实现的优势，将在我前面提到的配套文章中进行深入讨论。

我想各位将会发现很多企业业已认识到的事实：在 SDLC 和 IT 技术中越多地使用虚拟化技术，您就会发现越多的使用案例。尽情享受虚拟化带给您的无穷优势吧！

Andrew Binstock 现任 Pacific Data Works LLC 首席分析师。该公司专门从事技术白皮书业务。他将在 9 月于纽约举行的 InfoWorld 虚拟化高管论坛 (InfoWorld Virtualization Executive Forum)上发表演讲。您可通过 abinstock@pacificdataworks.com 与他取得联系。