级别： 初级 Leigh Williamson, IBM 杰出工程师 , IBM
Dr. Gili Mendel, 资深技术主管（STSM），Rational Asset Manager 架构师, IBM
Grant Larsen, 资深技术主管（STSM），资产管理首席架构师, IBM
Greg Rader, 软件开发监管解决方案架构师, IBM
2009 年 4 月 27 日 
了解在软件开发的背景下，最终软件库（Definitive Software Library）是怎样弥补软件交付与运作之间的缺口的，其中包括了组成解决方案的产品，以及它们是怎样联合起来以减少业务风险并提高效率的。
来自 The Rational Edge。
没有人会否认今天的商业环境，要求很高层次的谨慎与管理。风险是如此巨大人们在商业活动中必须保持清醒的头脑。软件交付过程也不例外。因为软件一般都处在大多数商业进程的核心，所以软件交付通常要比其他的商业过程，更能吸引人们的注意力。
在过去的十年间，软件交付公司在管理源代码以及它们产生的其他开发组件方面，正变得越来越有效率。许多公司采用了复杂高级的版本控制以及变更管理系统，例如 IBM® Rational® ClearCase®以及 IBM Rational ClearQuest®，以获取对存在于项目背景下的多种更改请求以及代码版本的控制。也有些公司自动化了对一些产品的构建过程，这些产品包括 IBM Rational Build Forge®，这种软件产生了记录在每个版本中版本的多种材料。
在 IT 操作内也做了相似的研究。Information Technology Infrastructure Library （ITIL®）获得了广泛的关注，许多 IT 操作公司转向像 IBM Tivoli® Change 以及 Configuration Management Database 这样的工具，以获取对整个企业中，各种应用，组件以及服务的控制。
但是，许多 IT 公司仍然挣扎在开发和操作的界限上。构建一般从开发的源代码库中开始，并指向没有伴随元数据的 FTP 站点或者共享文件。就算构建的版本号码记录在文件名或者一些文件结构中也一样。当操作接受一个新构建以部署时，它们注册了配置管理服务器（CMDB），但是并不会在审计单，材料或者质量日志上显示出来。尽管拥有好的开发和管理进程，缺乏真实端到端管理的 IT 公司，仍然挣扎在这个严峻的领域内。
本文描述了一个软件交付公司是怎样获取控制，并建立它所产生或者购买的软件，然后投入应用。它描述了参入方案的产品，以及那些产品之间的集成，还有展示方案值的使用说明。
开发/操作失去联系
开发与操作之间失去联系的后果是十分严重的。当操作组无意识的应用软件的版本，没有得到合适的测试或者检查时，商业机构就会遭受服务商或者安全部门的严重损失。当部署的软件包含有未认证或者未授权的组件时，商业公司可能就会暴露在金融和/或者法律风险之下。
1
考虑为接受一种新的软件构建，以处理信用卡信息的应用的部署团队。Payment Card Industry Data Security Standard （PCI DSS）需要所有的处理信用卡的应用，必须得到安全缺陷的检查。
2
就算应用的前面版本得到了检查，部署团队是怎样确认他们准备部署的新版本，将不会暴露在隐藏在新功能中的业务中的呢？在部署新版本到产品中之前，部署团队需要决定它已经被浏览过了，浏览已经被检查过了，而且一个已授权的版本管理员会证实没有检测到显著的缺陷问题。没有定义良好的，管理良好的切换，这种保证不能得到确认。
或者考虑一个从因特网上下载第三方组件，以及含有部分应用的组件的开发团队。如果应用在没有满足许可协议的前提下得到了部署，那么现在业务就会侵犯许可协议，并遭受法律的制裁。
除了可能由于开发和操作之间脱节切换发生的更加严重的后果，延长的交流圈也会导致延迟的部署，并失去业务机会。糟糕的交流还会延迟故障排除过程，这将会导致冗长的系统赘余以及用户抱怨。
本文中描述的方案，平衡了 IBM Rational Asset Manager 和 Tivoli Change 以及 Configuration Management Database 的协作以及管理功能，以确保开发和操作之间的更加有效，可靠的切换。它还处理发布管理员的需要，这些管理员决定了是否需要部署或者不需要部署一个版本。
什么是一个最终软件库（Definitive Software Library）？
团队最终软件库（Definitive Software Library），或者 DSL，来自 ITIL V2 规则，并参考软件图像以及相关信息的中央储存库。一个 DSL 也许会参考最终媒体库（Definitive Media Library），或者 DML，又或者 ITIL v3。软件的确定授权版本，软件记录文件，许可证信息，以及其他相关信息都会参考该库。在 IT 环境中，会需要软件中间件，应用图像以及供应脚本以进行开发，在开发中，开发员会找到允许的组件（开发源组件，赞成的服务，或者内部构件）以进行开发；更重要的是，确保可以构建和测试组件的应用。它们可以 促进再使用，以及开发机构内的稳定性，并使得管理达到高级的预测性。
创建一个最终软件库（Definitive Software Library）
IBM 推荐使用联邦方法，以有效的建立能够联系并促进开发和操作有效合作关系的 DSL。在开发端，Rational Asset Manager 管理每一个软件图像的通过的主拷贝。这些图像与开发以及测试文件存储区域隔离开来，就像 ITIL 推荐的那样。为了管理并促进这种进程，Rational Asset Manager 合并了与决策有关的信息，并将构建本身与质量日志、缺陷检查结果联系起来。当团队需要理解软件是怎样部署有关的具体信息时，它们可以通过与相关资源有关的图像来导航，例如供应脚本，白板以及指导文章等等；或者使用与图像相关的论坛来进行合作。为了保持对更改赞成的投资者的注意力，Rational Asset Manager 在更改发生时，提供通过 e-mail 或者 RSS/Atom 种子提供发送通知的签署功能。
在操作端，Tivoli Change and Configuration Management Database 追踪 IT 环境内软件是怎样部署的，以及与开发相关的细节信息，例如更改，Service Level Agreements（SLAs）性能，或者许可权使用。当一起使用时，Rational Asset Manager 和 Tivoli Change 以及 Configuration Management Database 能够将操作和开发同时联系起来。
对于 Rational Asset Manager 赞成的新软件图像来说，它能够作为配置项（CIs）而导入 Change 和 Configuration Management Database （CCMDB）。保持存在于 Rational Asset Manager 中软件图像资源和 CCMDB 中软件图像 CIs 之间的关系，允许其他方向上的背景内导航。
当开发队需要理解软件是怎样应用到机构中时，他们可以简单的从开发端导航到开发端，并检查产品层次的统计数据。当操作经历了产品中软件的问题之后，他们可以快速的决定谁拥有这款软件，甚至是哪一张测试会在版本之前的细节信息。更为重要的是，操作可以确保部署到产品中的图像在应用到产品之前，得到了合适的检查和评审，这可以降低风险并增加机构内的稳定性。图 1 显示了支持这种高层次追踪性的 DSL。
图 1：建立最终软件库（Definitive Software Library）的联邦方法
图 2 显示了开发和操作是怎样通过 DSL 来平衡不同的观点的。
图 2：资源的开发与操作视图
图 3：Rational Asset Manager 中软件图像与 CCMDB 配置项参考之间的关系
如果您想要得到关于怎样建立 Rational Asset Manager 和 Tivoli Change 还有 Configuration Management Database 之间集成的具体信息，您可以通过以下演示获得参考：建立 Rational Asset Manager 和 Tivoli Change 还有 Configuration Management Database 之间的集成
如果您想要得到关于怎样建立 Rational Asset Manager 和 Tivoli Change 还有 Configuration Manager 之间集成的具体信息，您可以通过以下演示获得参考：怎样建立 Rational Asset Manager 和 Tivoli Change 还有 Configuration Manager 之间的集成
推广一个最终软件库（Definitive Software Library）
一旦建立了一个 DSL，它需要推广到软件图像中。虽然这可以通过手动完成，但是一个更加有效的方法，就是利用 Rational Build Forge 提供的自动化带来的优势，以及遵循和构建之间联系，并检查构建和发布过程。
Build Forge 使用一个适应性的框架来帮助开发团队标准化和自动化重复性的工作。它集中了，自动化了并记录了整个的构建和发布过程，降低手动操作风险以及以及人为误差，日期错误和不同的意见。它集成了版本控制，测试以及缺陷探测系统，以提供完整的记录和追踪性，以便回答诸如“前面的版本发生了什么更改？”，“谁做了更改为什么要更改”以及“它解决了什么缺陷”之类的关键问题。图 4 显示了在 Build Forge 得到自动化的构建/发布过程。
图 4：Build Forge 管理构建和发布过程的步骤
Build Forge 平衡了一系列与 Rational Asset Manager 有关的 Ant 脚本，并访问Rational Asset Manager API。这些脚本可以用于下载附属来自 Rational Asset Manager的组件（以确保在构建中只使用允许的组件），或者返回至可以由发布管理员检查和批准的 Rational Asset Manager 候选构建。当 Build Forge 采用 Rational Asset Manager 的图像时，它就能向相关的组件提法合适的类别和附属物。
图 5 显示了注入到构建以及 Build Forge 中的 Ant 脚本。该行从 <ram:开始，这代表了使用 Ant 脚本的步骤。
图 5 ：访问 Rational Asset Manager API 以访问新构建的 Ant 脚本范例
点击放大
可以向 Build Forge 中的构建还有发布过程，添加额外的步骤以浏览构建中的安全性缺陷并确保代码的质量。IBM Rational AppScan Build Edition 和 IBM Rational Software Analyzer 可以提供与在 Rational Asset Manager 中发现的相似 APIs，它们可以使用执行这些步骤。
在浏览完成以后，Build Forge 会再一次访问 Rational Asset Manager，只有在这一次之后，它才会建立前面指向 Rational Asset Manager 的构建资源，与由Rational Appscan 和 Rational Software Analyzer 产生的浏览结果之间的联系。它创建了可以由发布管理员检查的构建资源的综合视图，而且一旦被批准，在投入生产之前，应用的操作可以确保图像得到合适的检查。图 6 显示了 DSL 是怎样使用上面描述的产品和程序，来得到推广的。
图 6：推广 DSL 与新的软件构建
推广 DSL 的另一种方法，就是利用 IBM Rational Asset Analyzer 和 Rational Asset Manager 之间的集成关系。集成的具体细节将会在接下来的后续文章中得到讨论，这些文章会重点讨论支持影响分析的 DSL。
结论
创建并推广最终软件库（Definitive Software Library）是走向开发与操作之间有效合作的重要一步。通过更有效的协作部署的软件，操作和开发都会从确保部署的软件安全，以及有效质量，还有允许发布的保证中收益。通过在构建以及发布中减少失误，公司可以通过降低风险，减少故障时间并提高效率来从中收益。
注意
-
http://www.itil-itsm-world.com/itil-5.htm
-
https://www.pcisecuritystandards.org/pdfs/navigating_pci_dss_v1-1.pdf
参考资料 学习
讨论
- 参与论坛讨论。
- 已经专门为 Rational Edge 文章创建了一个 新讨论区，因此现在您可以在此论坛中分享您对本文、本期期刊其它文章或我们过往期刊上的其他文章的看法。查阅您遍及世界的同行所阐述的观点，创建您自己的讨论，或者加入正在进行中的讨论。点击 这里 开始。
-
全球 Rational 用户组社区。
作者简介  | | | Leigh Williamson 是一名 IBM 杰出工程师，从 1988 年以来一直工作在奥斯汀的德克萨斯实验室。在这段期间，他参与了许多 IBM 的主要软件项目，包括 OS/2、DB2、AIX、OpenDoc、Java、Component Broker，以及 WebSphere Application Server。他目前是 Rational 开发自动化产品线的高级架构师，包括 Build Forge，他也是核心 Rational 开发委员会的一名成员，并且对 Rational 品牌的所有产品在战略方向上具有影响力。在工作于 Rational 产品之前，他作为 Application Server 的系统管理组件的架构师，在 WebSphere 开发实验室工作了七年。他拥有奥斯汀的德克萨斯大学的计算机工程硕士学位。 |
| | | Gili Mendel 是一名 IBM Master Inventor，并且是一名资深技术主管。他从 1993 年在 IBM 工作，领导许多不同软件产品的开发 —— 从 AIX 集群的多并口设备驱动程序，到基于 Eclipse 的工具。他拥有计算机科学的博士学位，目前是 IBM Rational Asset Manager (RAM) 产品的首席架构师。 |
| | | Grant Larsen，IBM Rational 软件资产管理的首席架构师，通过过程、标准、工具和可重用资产，例如模式，推动基于资产的开发策略，改善软件开发投资。
|
| | | Greg Rader 是一名 IBM Rational 的解决方案架构师，他帮助确保我们提供的跨产品解决方案交付我们客户所期望的价值。他在 1992 年获得了桑佛德大学的数学学士学位，于 1994 年获得了西佛罗里达大学的计算科学和软件工程硕士学位。 |
对本文的评价
| 
