专利名称：用于管理可修补软件系统的方法和装置的制作方法
用于管理可修补软件系统的方法和装置
相关技术
本申请是于2005年8月10日提交的美国申请No.ll/201.959的继续申
请，上述申请的全部教导通过引用而被结合于此。
背景技术：
在可修补软件系统(patchable software system)的情况中，"补丁" 或者"软件补丁"具有两种含义。 一种含义是动词，其涉及通过被设计并 测试在目标机器上运行的程序来增加、修改或卸载系统中的文件或设置。 第二种含义是名词，其涉及正如对于上述第一种含义中描述的改变的交付 机制(deliverymechanism)的程序本身。两种含义都与这里的描述有关。
单词"交付内容(deliverable)"用于涉及在特定补丁中包含的文件 或设置。系统状态、状态(独立的)或者目标机器状态都涉及特定系统或 目标机器中可描述的一组文件和设置。系统中的不可控改变涉及卸除补丁 判断系统或目标机器的状态的能力的任何状态修改。对系统的任何引用旨 在表明跨越一个或多个目标机器(服务器或计算机)的文件或设置的集 合。
对现有系统打补丁一般涉及建立关于目标机器的已知操作状态。这意 味着在应用或卸载补丁之前我们已经知道可能受该补丁影响的所有文件和 设置的状态，以便维持稳定运行的软件系统或产品。"手动地"对系统增 加任何改变(即，在没有用于检测和控制那些改变的编程接口的情况下) 将使该系统置于未知状态。这使得补丁的增加具有潜在危险，因为被打补 丁的文件可能己经被增加、更改或者已经从所期望的系统中被卸载，其 中，该补丁被设计在所期望的系统上运行并且可能已经在同样的情况下经 过测试。
根据下面按照附图所图示的内容对本发明的实施例的更具体的描述， 本发明的前述和其它目的、特征以及优点将变得很明显，在附图中，相同 标号在所有不同示图中表示相同部件。附图并不一定是成比例的，而是强 调说明本发明的原理。图1是采用本发明的实施例的计算机网络的框图； 图2是在图1的网络中使用的处理过程的实施例的流程图；以及 图3是图1的示出本发明的实施例的处理过程的计算机网络中的端用 户系统的框图。
具体实施方式
下面是对本发明的优选实施例的描述。一种通过创建特定补丁来管理特定软件补丁 ("补丁")的部署的方 法和相应装置，其中，所述特定补丁包括至少一个文件和与所述特定补丁 关联的信息，该信息用于防止在该特定补丁之上安装其它补丁。在优选实 施例中，该信息不会阻止在其它补丁之上安装该特定补丁，其中，没有指 定按照此方式对待其它补丁。该特定补丁可以是"临时补丁"，因为临时 补丁通常被指定作为一种下述类型的补丁在没有首先卸载该补丁的情况 下，不应当在该补丁上安装其它补丁。临时补丁以及安装和卸载的处理过 程的细节在下面结合图1-3提出。应当明白，使用术语临时补丁的描述也 适用于更一般的补丁。在某种意义上，特定补丁可以是被控制交付的补丁，其在被构建成交付补丁之前通过标准质量检查处理或其它形式"官方版本(official releases)"的处理而受到版本控制。下面的示例可能是参考被控制交付的 补丁提出的，但是应当明白，该示例可应用于更一般的补丁。被控制交付 的补丁还可以避开标准质量检查处理或其它形式的官方版本的处理，并简 单地具有按照标准方式记录的内容或关于其本身的信息，以便接收计算机 的状态保持已知。这样的补丁不同于未受控制的补丁，未受控制的补丁在 不受中间质量保证处理或未按照官方方式记录的情况下直接从工程师电邮 或发送到消费者。临时补丁可以包括诊断软件或用于更正软件程序中的软件错误的临时 软件。诊断软件或临时错误更正软件在这里还被称作"工程测试"软件。 临时补丁 (工程测试补丁)与"工程专用"补丁 (未预定版本)以及"服 务版本"补丁 (预定的)不同，因为后两种补丁在以后被期望由软件开发 者来维护。利用本发明的实施例，临时补丁不再从软件工程师被直接交付给消费 者。替代地，软件工程师与编程接口合作，该编程接口在这里称为用于检 测或控制软件系统中的改变的补丁管理器或者在其它任务中跟踪消费者机 器中的软件的状态的补丁。补丁管理器的跟踪可允许安装其它软件补丁， 而不会产生因在临时补丁上安装特定补丁而可能导致的不利作用。为了安 装特定补丁，通过卸载临时补丁将消费者机器中的软件设定成已知状态。 一旦处于已知状态，就可以安装特定补丁。实际上，临时补丁可以交付给补丁管理器，补丁管理器然后直接将该 临时补丁转发到消费者机器或者接口 (例如，公共知识库)，以便被消费 者机器下载。补丁管理器可以对临时软件补丁的记录进行维护、对临时软件补丁进 行存档或者对在其中安装该临时补丁的可修补软件系统(即，消费者机器 中的软件系统)的状态进行维护。补丁管理器或临时补丁本身可辅助卸载 该临时补丁，以允许以后安装其它补丁。本发明的实施例提供了通过软件补丁 ("补丁")控制向系统增加一 个或多个改变的机制，所述软件补丁使系统拒绝任何另外的修补，直到该 临时补丁从该系统中卸载为止。这可以使目标系统的文件和设置在增加改 变之后返回到已知状态，在利用本发明之前，所述改变将会引入到被控制 的软件补丁开发路径之外的目标系统中，从而潜在地使该系统不能被修补 并且潜在地导致对该系统的不期望或无法预料的行为。如果补丁是针对不 同的文件或设置集合而设计和测试的，则会出现上述结果。根据本发明的 实施例的补丁具有判断状态的能力，以便可编程地应用控制对目标机器或 系统进行安装、修改或者卸载补丁的规则。术语"工程测试"或"ET"涉及表现出上述行为的一种补丁。此名称来自特定用途，S卩，例如向系统增加诊断软件代码，在对该系统进行任何 补丁之前期望先卸载了该软件代码。然而，其用途在这里往往涉及不止一 种特定的实施方式，所述特定实施方式要求一种对补丁的交付方式。工程测试补丁 (即，临时补丁)可以通过在目标机器上留出针对在该ET之后应用的补丁的关于其本身的充分的信息而检测该ET被安装并且在 该ET被卸载之前阻止安装来将其本身与其它类型的补丁 (例如，"工程 专用"补丁和"服务版本"补丁)区分开来。本发明的一个实施例包括用 于"标记"或通知系统其在某种程度上处于可由其它补丁来检测的未知状 态的机制。该机制取代了以改变其状态以致于补丁不能与其被设计并在其 上测试的系统进行作用的任意方式来手动对系统进行干扰。下面的内容说 明在示例实施例中的文件或设置的状态流(利用单个大写字母来表示文件或设置)基础系统(非ET补丁所期望的) A B在安装ET补丁之后 ABE安装非ET补丁失败之后(状态保持不变) ABE在卸载ET补丁之后A B安装非ET补丁成功之后ABC该示例表明都利用了本发明的实施例的两个可能的补丁之间的文件状 态改变。本实施例包括一种可使非ET补丁 (即，补丁 C)安装失败的机 制。在本实施例中，第二补丁 (补丁 C)检测到ET补丁 (补丁 E)并且 停止安装。在另一实施例中，ET补丁 (补丁E)其本身可以阻止第二补丁(补丁 C)的安装，而不需要在第二补丁中配置逻辑。在又一实施例中， 接收第二补丁 (补丁 C)的软件系统具有逻辑地防止覆盖该ET补丁 (补 丁 E)的安装管理器或驱动器，而无需卸载该ET补丁。在另一实施例中，逻辑位于远离端用户系统之处，例如处于从其可下载补丁的公共知识 库中，而且逻辑也可从远处控制卸载ET补丁 (补丁 E)和安装其它补丁 (诸如补丁C)的处理过程。因此不可控改变被阻止，从而导致较安全和较可靠的补丁系统。安装 补丁的动作自动受到保护，防止将目标机器设置成未知状态以及潜在的不 可修补的状态。产生依赖特定机器状态来被可靠并重复地安装的补丁的任 何软件产品都可以利用本发明的实施例。在诸如网络设备的嵌入式系统上运行的修补软件变得越来越重要。许 多网络服务提供商寻求这样的能力。在进行修补时，存在这样的效用，保 持跟踪哪个版本正在运行以及在尝试新补丁/功能时考虑消费者可与工程师 更近地合作。利用本发明的实施例的软件能够检测实验软件代码并且不再允许安装 另外的补丁。按照这种方式，可以发生工程师的测试，而不会因安装另外 的软件或补丁更新程序而不利地影响机器操作。因为由于某个原因或其它原因，导致问题出现的环境不能在实验室再 现，因此不能对一些修补进行本地验证。在这样地情况下，工程师可能需 要向消费者提供在产品软件代码中不能得到的额外信息的非产品软件代 码。安装或者之后卸载该软件代码的优选方式是将其绑定成临时或测试补 丁，但是与一般补丁不同，该临时补丁不能结合到主要的内容源支路(source branch)(例如，开发发行的程序)中，并且不能与以后的补丁 兼容。临时补丁往往旨在作为临时诊断工具。在可修补管理系统中，除了以下一些重要的不同之处外，工程测试补 丁 (其不能成为软件产品的一部分并且不能被维护、被版本控制等)几乎 表现得和"工程专用"补丁 (其可成为软件产品的一部分并且可被维护、版本控制等) 一样工程测试补丁不能从来自发行组的编译系统的文件创建。绑定到工程 测试补丁的文件由开发该补丁的工程师上载。这使得工程师可以在任何所 需环境下均可以利用所需要的任何不常见的编译配置来编译该文件。因此，软件控制库分支不直接涉及按照创建工程专用补丁的方式来创建工程测试补丁。 一旦工程师对该补丁的请求被批准，该工程师直接转向 上载文件；无需根据"发行工程"来进行编译。在一些实施例中， 一旦工程测试补丁安装在系统中，就不能再安装任 何种类的其它补丁，直到该工程测试代码被卸载为止。工程测试代码不能结合到服务版本或维护版本中，因为这些版本是包 括更新软件的常规版本的软件或者是因之前的服务而发布的工程专用补丁 或者维护版本。一旦完成工程测试补丁，就不能更新对于任何有关软件错误的具体缺陷跟踪系统(Corporate Defecttracking System) (CDETS)的记录。由于不能更新CDETS，因此消费者没有方法能够获得工程测试代码， 除非工程师提供该代码。除了上述例外，工程测试代码表现的就像工程专用补丁一样。 图1是采用本发明的实施例的网络100的框图。网络100包括开发软 件代码服务器105、源控制库110、具有发射机(Tx) 117的补丁管理器 115、公共知识库120以及端用户系统125。开发软件代码服务器105、源 控制库110、补丁管理器115和公共知识库120都可以是向端用户系统 ]25提供软件和软件补丁或者服务版本(service releases)的软件公司的内 部网络的一部分。在实施例中，开发软件代码服务器105可以处于软件工程师按照对软 件进行的部分惯例改进或者响应端用户作出的请求来开发软件代码的位 置。源控制库110可以处于由软件工程师创造的软件因存储和版本控制或 其它控制的原因而通过通信路径130a被发送的位置。补丁管理器115通过通信路径130b从源控制库110接收源代码或其它 形式的软件代码。在本实施例中，补丁管理器115提供多种类型的功能， 例如，将来自源控制库110的软件捆绑成可以通过发射机117发送的档案 文件(即，创建补丁)，以便部署在网络节点(诸如端用户系统125)并 安装到端用户系统125中。该档案文件可以包括一个补丁或多个补丁的压 縮表示。公共知识库120通过通信路径130c从补丁管理器115接收档案文件或其它形式的软件。公共知识库120作为补丁管理器115和端用户系统125之间的接口，允许端用户从软件公司获取档案文件或其它形式的软件。存在端用户直接与工程师联系并且向工程师陈述端用户系统125中出 现的问题的情况。响应这样的请求，工程师可以开发用于诊断端用户系统 125中的问题或者修补端用户系统125中的软件错误的软件代码(例如， 工程测试补丁)。 一般地，工程师通过网络路径135将工程测试软件发送 给端用户系统125，而非通过受版本控制的软件通常采用的路径130a-130d。网络路径135可以包括经由诸如因特网的广域网(未示出)的路 径。关于此与端用户进行的"不受控制"的行为的问题是端用户系统125 然后具有了对于补丁管理器未知的工程测试软件，其中，补丁管理器115 知道通过更新软件的常规路线交付给端用户系统125的软件的状态。此不 受控制的行为以后可能引起问题，因为端用户系统125中的软件的状态是 未知的。正如本领域技术人员所明白的，对此不受控制的软件进行更新或 修补可能导致多种层次的问题。因此，在本发明的实施例中，通信路径 135被断开，正如由"X" 140所表示的。在图1示出的本发明的实施例中，工程测试代码采用的路径通过补丁 管理器115。按照此方式，补丁管理器115可以包括可交付的档案文件中 可以在端用户系统125中部署的信息(例如、标记、标号、状态指示符、 补丁或补丁中的文件的名称等等)，所述档案文件还可以包括临时补丁， 临时补丁可以包括工程测试软件。该信息可用于防止以后的补丁更新程序 (patch updates)覆盖具有工程测试代码的软件或者补丁。通过防止以后 的补丁更新程序覆盖工程测试代码，端用户系统125中的软件不会受到在 前一软件(或补丁)更新程序和下一软件或补丁更新程序之间在软件系统 中安装中间工程测试软件的不利影响。通过根据本发明的实施例的新的处理过程将工程测试代码转发到端用 户系统的处理过程是从开发代码服务器105经由通信路径145a到补丁管理 器115。该通信路径145a绕过源控制库110，因为工程测试代码不是在以 后的维护中所需要的软件。工程测试代码可以从补丁管理器115通过前述通信路径130c或者不同的通信路径145b被传送到公共知识库120。同 样，工程测试代码可以从公共知识库120通过前述通信路径130d或者不 同的通信路径145c被传送到端用户系统125。图2是通信示图，该图示出了工程服务器105、补丁管理器115、公共 知识库120和端用户系统125以及这些设备之间的各个通信。处理过程 200以端用户发现软件"错误"(步骤205)开始。端用户可选地通过端 用户系统125联系可选地经由工程服务器105的工程师来请求对软件错误 进行更正。工程师创建调试(即，工程测试)代码(步骤210)。工程师 通过工程服务器105将调试代码上载到补丁管理器115 (步骤215)。补丁管理器115将调试代码捆绑到安装程序中(步骤220)。补丁管 理器然后将该安装程序发送给公共知识库120 (步骤225)。补丁管理器 115还通过工程服务器105通知工程师安装程序已经发送给公共知识库 120 (步骤230)。当工程师接收到通知时，工程师通知消费者安装程序已 经被发送给公共知识库120 (步骤235)。端用户在端用户系统125处接 收此类通信。之后，端用户系统125从公共知识库120检索此安装程序 (步骤240)。公共知识库120响应请求将安装程序提供给端用户系统125 (步骤 245)。端用户系统125应用调试软件代码(歩骤250)，该调试软件代码 然后用于帮助调试软件系统，判断是否包含端用户先前指定的"错误" (步骤205)。在应用该调试代码(步骤250)之后，端用户系统125通 知工程师(步骤255)。工程师利用工程服务器105找出对于该软件错误 的调整方法或者重复创建另外的调试代码、向补丁管理器115上载新的调 试代码等的处理过程(步骤260)。在以后某时，端用户系统125在安装任何其它软件补丁 (在一实施例 中，该其它软件补丁包括其它临时软件补丁)之前先卸载具有该调试代码 的补丁 (步骤265)。按照这种方式，软件的状态从具有工程测试代码的 状态返回到已知状态，该已知状态可以通过由软件公司提供的标准处理步 骤并且具体地通过补丁管理器115来更新，其中，补丁管理器115允许端 用户系统125以已知并且无误的方式继续工作。为了在存在工程测试代码时利用新的补丁来更新端用户系统125，在 安装以后的补丁之前，补丁管理器115提供了其利用标记或信息创建的例 如可由安装程序/卸载程序检查的档案文件，所述标记或信息被写入优选地为端用户系统125或与该端用户系统125有关的系统中的寄存器、登记簿 或其它位置。该标记或信息可以具有防止覆盖包含工程测试代码的补丁的 已知值、类型或者状态，或者可以具有当其被发现为未知时同样防止覆盖 的未知值、类型或者状态。例如，与工程测试代码有关的名称可以存储在 登记簿中。名称本身可以指示以后的检査补丁或者安装程序不应当覆盖该 工程测试代码，或者所存储的名称不会被以后的检査补丁或安装程序辨认 出来但具有同样的防止作用。图3是端用户系统125以及与判断先前提供的补丁 (在此情形中为软 件系统300使用的临时补丁 310)是否可以被覆盖或者必须首先被卸载的 示例实施例的框图。在从公共知识库120接收到新的补丁 315之后，新补 丁 315中的安装程序/卸载程序330利用逻辑检査端用户系统125的登记簿 305中的标记322的状态(步骤320)。在示例中，标记322是ET=YES， 这表明先前提供的补丁 310是包括工程测试代码的临时补丁并且在没有安 装的情况下不会被覆盖，此信息又回报给安装程序/卸载程序330 (步骤 325)。作出响应地，新补丁 315中的安装程序/卸载程序330卸载该临时 补丁310 (步骤340)。在卸载该临时补丁 310之后，安装程序/卸载程序330安装新补丁软件 335 (步骤345)。安装程序/卸载程序330将新标记350 (ET=NO)写入 登记簿305 (歩骤355)，因此，在安装安装程序/卸载程序330之后，在 端用户系统125接收的下一个补丁可以知道该新补丁 315在被覆盖前是否 要卸载，在本示例中不是此中情况，因为其不是有关标记提出的工程测试 代码。虽然已经结合优选实施例具体示出了本发明，但是本领域的技术人员 应当理解，在不脱离本发明由所附权利要求书包含的范围之内可以作出各 种形式上和细节上的改变。例如，开发代码服务器105、源控制库IIO、补丁管理器115和公共知识库120可以设置在不同的机器上，或者设置在同一机器上(该机器按照图1所示进行逻辑操作)。另外，应当明白，通信路径130a-130d以及 145a-145c中的一些或所有路径都可以使用标准的或者定制的通信路径或 协议(例如，包括TCP/IP通信协议)并且也可以使用有线、无线或光纤 通信路径或相关协议。除了公司服务器之外，公司还可以提供防火墙(未 示出)，通过该防火墙，来自端用户系统125的通信可能不会通过，并且 来自开发软件代码服务器105的通信可能不会通过。按照这种方式，公共 知识库120可以是端用户系统125接收软件补丁 (包括工程测试代码)的 唯一接口。这有助于防止端用户系统125中的软件的状态对于补丁管理器 115变成未知状态。应当明白，补丁管理器115可以用于对临时补丁的记录进行维护、对 临时补丁进行存档或者对在其中安装此临时补丁的可修补系统的状态 (即，跟踪端用户系统125中使用的软件的已知状态)进行维护。所述信 息可以被补丁管理器115用来卸载临时补丁，从而允许以后安装其它补 丁。图2的流程图是示例流程图，并且结合图2所描述的一些步骤可以以 其它顺序、其它方式出现，或者一点儿也不出现。例如，可以通过端用户 访问网站来得知该发送或者工程师可以使用电话告知端用户此发送来发生 返回给工程师的通知(步骤230)或者从工程服务器105到端用户系统 125 (步骤235)的发送到公共知识库的通知(步骤225)。应当明白，在 不脱离本发明的原理条件下，在上述参考图l和图2描述的实施例可以采 用其它计算机系统或处理过程。在图3中，用于判断补丁 (例如，工程测试、工程专用或服务版本) 是否可以被覆盖或首先被卸载的逻辑可以设置在端用户系统125中或可以 在端用户系统125中被执行。逻辑根据其来作出判断的标记或者指示符可 以存储在(i)端用户系统125的补丁本身中或者(ii)存储在(a)端用户 系统125或(b)端用户系统125之外的诸如公共知识库120或可以被端用 户系统125访问的其它网络节点的寄存器或类似装置中。
权利要求
1.一种用于管理软件补丁的部署的方法，该方法包括创建软件补丁，所述软件补丁包括至少一个文件；以及将防止在所述软件补丁之上安装其它软件补丁的信息与所述软件补丁相关联。
2. 如权利要求1所述的方法，其中，所述信息被存储在用来安装软件 补丁的安装程序访问以判断在没有首先卸载其它软件补丁的情况下是否可 以安装软件补丁的位置上。
3. 如权利要求1所述的方法，还包括从软件补丁管理器接收所述软件 补丁。
4. 如权利要求1所述的方法，其中，所述软件补丁包括诊断软件。
5. 如权利要求1所述的方法，其中，所述软件补丁包括用来更正软件 程序中的软件错误的软件。
6. 如权利要求1所述的方法，还包括维护所述软件补丁的记录。
7. 如权利要求1所述的方法，还包括对所述软件补丁进行存档。
8. 如权利要求1所述的方法，还包括维护在其中安装所述软件补丁的 可修补软件系统的状态。
9. 如权利要求1所述的方法，还包括辅助卸载所述软件补丁。
10. —种用于管理软件补丁的部署的装置，该装置包括 软件补丁管理器，该软件补丁管理器创建包含至少一个文件的软件补丁，并且将防止在所述软件补丁之上安装其它软件补丁的信息与所述软件 补丁相关联；以及与所述软件补丁管理器通信的发射机，该发射机将所述软件补丁发射 到部署位置。
11. 如权利要求IO所述的装置，其中，所述信息被存储在用来安装软 件补丁的安装程序访问以判断在没有首先卸载其它软件补丁的情况下是否 可以安装软件补丁的位置上。
12. 如权利要求IO所述的装置，还包括源控制库，并且其中，所述软件补丁管理器接收所述文件，所述文件不包括经过所述源控制库的文件。
13. 如权利要求10所述的装置，其中，所述软件补丁包括诊断软件。
14. 如权利要求10所述的装置，其中，所述软件补丁包括用来更正软 件程序中的软件错误的软件。
15. 如权利要求10所述的装置，其中，所述软件补丁管理器维护所述软件补丁的记录。
16. 如权利要求10所述的装置，其中，所述软件补丁管理器对所述软 件补丁进行存档。
17. 如权利要求10所述的装置，其中，所述软件补丁管理器维护在其 中安装所述软件补丁的可修补软件系统的状态。
18. 如权利要求10所述的装置，其中，与所述软件补丁相关联的所述 信息辅助卸载所述软件补丁。
19. 一种用于管理软件补丁的部署的方法，该方法包括 用于创建软件补丁的步骤，所述软件补丁包括至少一个文件；以及 用于防止在所述软件补丁之上安装其它软件补丁的歩骤。
20. —种用于向消费者提供软件服务的方法，该方法包括 响应于由与软件系统连接的消费者提供的信息而写软件；以及 以第一软件补丁的形式向所述消费者提供所述软件，所述第一软件补丁包括防止在所述第一软件补丁之上安装对于其它软件的第二软件补丁的"f曰息。
全文摘要
一种用于通过创建包括至少一个文件特定补丁并且将防止在该特定补丁之上安装其它补丁的信息与该特定补丁相关联来管理软件补丁(“补丁”)的部署的方法和相应装置。在一些实施例中，不再将补丁从软件工程师直接交付给消费者。相反，软件工程师操作补丁管理器，以允许在不产生可能因在特定补丁之上安装而导致的不利影响的情况下安装其它补丁，其中所述补丁管理器可跟踪消费者机器中的软件的状态以及执行其他任务。为了安装其它补丁，通过卸载特定补丁将消费者机器中的软件设定成已知状态。一旦处于已知状态，就可以安装其它补丁。
文档编号G06F9/445GK101243393SQ200680029530
公开日2008年8月13日 申请日期2006年7月26日 优先权日2005年8月10日
发明者保罗·J·拉塞尔, 克里斯多佛·S·沃伦, 托马斯·N·科布, 曼珠纳莎·N·拉马纳斯普拉, 雷恩·J·沙夫特 申请人:思科技术公司