| UML软件工程组织 | |||
| |
|||
|
|||
System z 和 ClearCase z/OS Extensions：一种配置管理的数据驱动方法
作者:Brandt Onorato 来源： IBM
| 在这篇文章中，我将回顾IBM Rational ClearCase的两种实施方法和 ClearCase z/OS Extensions的集成（z/OS是系统z主机最常用的操作系统之一），还将描述为ClearCase存储库中包含的z/OS工件构建管理的数据驱动方法。在描述这一方法之前，我将首先描述对于这两类客户ClearCase和ClearCase z/OS Extension 能够解决的业务问题。 客户端的业务软件都随着时间——通过设计或者通过采购——发展到多平台环境，这意味着可以在Windows、Unix、System z ( z/OS)和System i系统下运行部分业务应用软件，并且这些应用软件大多数都通过为其他应用提供信息来相互通讯，或者作为终端用户的界面。这是成熟的IT系统中的普遍情形，这就是“跨平台的依赖关系”。配置管理解决方案必须能够协调这些跨平台的应用类型。 每一个平台解决一个真正的业务需要并依据指示执行工作，因此解决方案并不是在一个平台上调整应用软件，而其目的是了解业务操作技术，了解其如何在现代工作区域中进行演进以及业务如何使用这一技术。 在两个业务场景中，每一个平台拥有适合其不同周期及产品环境下的代码迁移过程，并且根据这些迁移每一个拥有其自己的适合的配置管理系统。这些不同配置管理系统的调整是最困难的，无论在哪种业务场景中这都是事实。 成熟的IT系统存在于多种硬件和软件平台以及继续在每个特定的平台上开发业务软件是无法改变的事实。导致这一复杂的情况的原因是什么？ 第一个原因与来自大约十五年前的一句预言有关：“大型电脑已经死亡”。贯穿IT行业的这一观点使得将软件从主机系统迁移到其他包括 UNIX、System i (过去是i Series)和 Windows 平台方面有重要突破。当然，就算没有“大型电脑已经死亡”这一观点，这些平台自然也在日益普及，但是这一转变的确对更好地利用其他平台起到作用。这一度导致大量的软件开发在多种平台上，而经过检验且可靠的主机软件仅处于维护状态。 第二个原因是dot.com迅猛发展，这依托于网络的日趋成熟。一开始，每个人想要一点网络不动产，从世界五百强到当地社区的夫妻店。网站起初看上去像突发奇想，但是很快商业界意识到网络作为客户、生意伙伴和内部用户相互交流的方式是多么有效。我们的需求世界就由此诞生了。这导致了可以利用网络和支持它的平台的新软件和工具的迅速发展。 网络和行业信息的发展正被传递引导使用现有平台的构架的发展，例如主机和AS400。随着大多数原始数据仍存在于这些平台上，与其他平台相互交流的需要变得极为重要。 基于所有平台的技术的出现和再出现使我们认识到了多平台这个现实；每个平台都有它的长处而且在商业中要最大化的利用每个平台的长处。 随着上面的软件开发动态日益发展，配置管理（CM）解决方案也随之发展。事实上，根据特定平台的需要以及在哪一平台上开发和部署认识到的方法软件，每一个CM解决方案完全独立于其他解决方案在发展。 许多公司创建自产的CM工具来满足他们自己特定的需要。软件提供商们也用很多的配置管理方案作出回应，大部分对单一平台还是很有用的。公司们会选择其中的一个方案或者创建一个去满足他们当时的需要。 与此同时，不管是通过购买还是对其商业需要作出回应，这些公司都在忙于为其软件结构增加平台。这就意味着这些公司继承了原有的配置管理方法，要购买一个附加的方法去满足新平台的需要，或者去定制自己的系统以满足他们的新要求。当业务跨平台增长时，配置管理解决方案的数量就成了公司软件资产的一部分。 自然地，很多公司经历过多种配置管理解决方案的危机。在一些情况下，不仅是针对每个平台有不同的配置管理，还有可能是多个配置管理方法针对一个单一的平台，提供商的一系列工具组合和公司自行设计的解决方案。这个奇特的现象经常发生在收购其它公司后，以及当代码迁移和重新培训开发团队的费用过高的时候。 另外，一些公司也要面对他们的配置管理方法的定制化因素。例如：某个提供商的一系列建议被选中，配置管理人员――基于对商业驱动器和可用性问题的考虑―――随着时间的推移，定制和提高了针对他们具体用途的解决方案。 在可预见的将来，这种做法把公司、职员和某一个单一的方法紧密联系了起来。但是，当职员间的摩擦发生以及商业模式增长时，这个方法不能改变自己以跟上公司发展的需要。与该方法紧密联系的开发团队不能跟上公司商业的发展。 对于遵循不同的开发过程，以及具有“跨平台依赖”的团队来说，这些是最平常的历史原因。现在，加上当今的IT需要――例如，强制要求遵循Sarbanes-Oxley 法案、治理、地域分布式的开发团队的管理――我们有一个非常复杂的软件开发过程和同样复杂的商业模式要操纵。 如上所述，我将描述两个真实的业务案例，它们都使用复杂的配置管理解决方案去管理IBM z/OS 系统。 案例1： 国内运输 第一个案例来自于运输业，我把这家公司称之为“国内运输”。 他们现在用的配置管理系统是自行设计的。虽然已经很顺利地用了许多年，但也出现了与 Sarbanes Oxley 遵从性相关的问题。他们自行设计的系统并不主动包含版本控制，所以系统不能准确地重新生成运行在生产系统上的工件。他们也不能在他们的执行周期内准确地追踪到工件的部署。他们的业务应用也发展到了跨平台的架构。 环境的变化也是一个因素。在收购了另一个美国南方的运输公司后（这个公司有自己的开发团队），他们希望把一些系统软件研发外包或放到离岸的地方。这就意味着研发要在两个不同的地方进行，两地要保持同样的过程并且在跨平台的应用上要协调一致。 案例2：C 部门 第二个案例来自于州政府，我把它称之为C部门。他们现在用的配置管理系统是一个混合的，以第三方的产品作为核心，并用定制的REXX，Clist 和ISPF的控制板作为接口。虽然这个定制的接口和第三方的产品能实现版本控制和追踪到部署的工件，这个架构是很多年前创建的。 制造和维护这个配置管理系统的雇员们早已经离开了这个部门。 另外，近来州内的退休政策的变化会使该州在近两年内失去将近三分之一的IT工作人员。 这样一来，该州会由于两个原因而处于不利地位：1. 由于针对第三方产品的定制，他们不能使用常规的维护，而他们此时正在运行没有支持的CA-Librarian。2. 在现存的就业人口中，任何一个懂得这个系统的人才在不久以后就会流失，因为他们即将退休。 该州的发展环境也在变化。 这个系统是很多年前建立的，现在需要修改以便满足该州现在和未来对软件发展的需要。现有的架构是固定在一个串行的－－IBM Rational 可能会称之为“瀑布式”－－开发过程上。他们用纸制办公和项目管理去防止开发者对他们的应用程序的覆盖以及代码回退。 实际上，州的立法机关促成了这个项目的大部分，即：政府部门的工作变化是随着法律变化的。法律变化随着政府的换届而改变，在任何一届政府的治理期间都是如此。 在我讨论C部门时，关于遵从性的新法律已经颁布，最后期限已经过去。所以他们的应用和开发队伍对整个系统已经在很大程度上作出了改变。 问题是他们的技术结构阻止他们在遵循法律要求的同时应用这个系统。并且，维护他们现存的配置系统花费过高，即：他们没有修改现存的配置管理系统以备长期需要的技术。 IBM Rational ClearCase z/ox 扩展介绍 这两个案例都需要一种管理他们的主机，构建、编译和部署 z/OS 工件的过程。z/OS扩展以ClearCase为特色，提供了用CLearCase作为主机和其它设备的单一存储的一种连接方式。 这就为两个平台提供了一个单一的控制点和一个单一的开发过程。 描述这种单一的存储方式需要一整篇文章。在此，我会简单介绍一下怎样用ClearCase 和z/OS扩展实现构建管理。 架构很简单。 一个z/OS的代理或运行在目标z/OS系统的启动任务，是通过TCP/IP和一个端口地址与ClearCase存储库进行通讯的。 这个CLearCase 主系统也有一个指向目标z/OS 系统的代理。 存储在 ClearCase 中的 z/OS 工件叫做VOB(版本化的目标基础)。 在主ClearCase和目标z/OS系统之间的构建和部署接口是PERL、远程构建命令集和PJCL 1 的组合。这个三部分的组合基本上可以运行任何主机工作，或利用中心存储的ClearCase存储库。 PERL是驱动语言，它控制构建或部署流，检查返回的代码，用设计好的构建和部署路径执行逻辑操作。 PJCL是JCL步骤的实际序列，JCL步骤操作发送到ClearCase代理中，然后在目标系统的启动任务中执行。远程构建命令集执行发送资源和PJCL的任务。这种设置和其它一些配置管理系统一样，和CA－Endevor一起运行可以和Processors相比较，和Serena的Changeman一起运行可以ISPF的框架相比较。 数据驱动的方法去实现配置管理利用存储在与单个源模块相关的存储库元数据，所以在z/OS系统下，这些将是构建组件。 一个构建组件包括这个资源模块用什么语言，是否包含DB2、CICS、IMS、MQseries等组件。这类信息存于ClearCase的元素级别的属性中。使用关于被存储元素的信息，构建引擎能够查询数据，并可以衍生出正确的 PJCL，以动态的构建元素。 除了存储关于元素和元素如何构建的元数据外，ClearCase项目级别的属性也被存储，它们和元素界别的特性相似，除了这些是关于与整个项目和z/OS的基础结构的。依靠基础结构，这些属性与系统库连接有关， 这些连接关联到Copybooks、装载元件、DB2子系统、CICS区域、IMS区域等，以及任何与适合z/OS环境的工件部署。例如,在一个简单的基于测试、QA 和生产 环境的执行周期中，项目级别的属性会存储数据以了解每个目标数据库、CICS区域，DB2子系统等，所有这一切在构建或移动任何一个以上的环境中都需要。 ClearCase环境变量也用于这种方法中，ClearCase环境变量存储关于设计好的执行周期的信息。例如，如果我正在创建一个测试环境，ClearCase变量可以得知下一个环境的定位，因为编译或部署都依赖于此方法。 用这种方法开发者并不要考虑如何构建或部署，配置管理系统（在本例中指ClearCase）有智能的构建引擎。它知道开发者在执行周期的位置，要构建什么，在哪构建以及怎样在合适的z/OS环境中部署。 迁移或配置元素级别的属性并不复杂。如果迁移来自于一个现存的配置管理方式――不管是自行设计的还是第三方的――这个数据应该在方法内部得到应用，通常是通过一个简单的报告。作为迁移的一部分，元素级别的属性可被当作资源文件存进ClearCase的存储库中，在上面描述的关于国内运输和C部门案例的两种操作中，信息以电子表格形式传送，然后以文本文件的形式读入程序中，生成命令集并分配属性。 如果现存系统中没有元数据或元素级别的构建属性，就需要进行清单分析。这种操作通常是在主机上进行，使用 amblist 工具。由此输出组件可以被确定下来。 ClearCase的设计结构与现行的z/OS基础结构或执行周期设计有关。它可以被设计在ClearCase内部，或者作为一对一的关系，跟现存的结构一样，也可以被修改以适应客户的需要。 在国内运输案例中，ClearCase结构是被设计成与现存的z/OS结构一对一的关系。在C部门的案例中，它需要被重新设计，形成开发过程中的并行关系。 一旦设计完成，项目开始， ClearCase管理员可以输入项目属性，主要是定义单个项目的迁移路径，因为它关系到z/OS的支持结构和执行周期。执行周期可被设计成连续的方式，即每个项目有相同的执行周期或者项目可以有灵活性去指向不同的支持环境结构，这些基础结构基于单个项目的要求之上。 下图解释了：1）分配元素级别属性的过程，2）分配项目界别属性的过程和3）决定构建引擎以及它怎样和与z/OS基础结构相关的ClearCase实现交互。在每个图标后都会有一个小总结。 分配元素级别的属性 
在C部门的案例中，迁移过程用一个有所有元素名字的文件及其来自于一个DB2表格的相关属性。数据进入到一个Excel表格，然后转成一个CSV文件，该文件的标签被界定了。之后读入一个PERL脚本文件import_attr.pl中，用这个数据建立一个Cleartool 命令的批处理文件去分配元素的属性。 输入的文件，虽然在这种情况下是一个DB2的表格，也可以是一个报告，能被像CA-Endevor或Serena的ChangeMan之类的主机配置管理方式生成。很多CM工具――即使是自行设计的――也会有这个功能。import_attr.pl脚本在标签界定的条件下可以读文件，创建Cleartool命令集。 在国内运输案例中，该任务被一个REXX exec 程序完成， 它分析主机上的数据，生成一个Cleartool命令集的批处理文件，该文件进入ClearCase主机，以批处理文件的方式运行。 import_attr.pl脚本会以域服务的一部分的形式传送，以便在迁移过程中帮助客户。 
SetZCCEnvAttr.pl工具被用于更新ZCCENV属性，该属性局是在项目级别定义的。 它的功能是定义和描绘出主机上的z/OS基础结构和执行周期。然后这个数据被构建过程查询，用以决定在执行周期中该项目的位置，如何移动。如果在开发过程中需要作出改变或需要一个不同的迁移路径，Clearcase管理员只需改变ZCCENV的定义，因为这个项目用的是SetZCCEnvAttr.pl脚本。为测试和QA构建引擎利用这个新属性，在新的执行周期中继续进行或迁移到新的z/OS基础结构中。 SetZCCEnvAttr.pl工具作为域服务的一部分进行传递，以在过程中帮助客户。这个工具在以上的两个案例中均可应用。 
在上面的使用模式中，建立脚本文件首先选取元素级别的构建属性。然后决定在执行周期中，应该在哪儿建立引擎，该引擎通过选取在项目开始是分配的项目属性建立。这些属性包括合适的目标加载库，SYSlib 连接，DB2子系统等。该执行周期也用ClearCase环境变量去确定引擎应建立在周期内部何处。 下一个阶段决定实际的PJCL需要在合适的地方建立引擎，通过创建PJCL，并且替代所有的在存储库中查询到的元数据。这创建了必要的PJCL， 并且每次执行一个创建步骤。 构建过程的进展通过STDOUT展示给开发者。在构建过程后期，创建的PJCL和所有的存储起来的输出程序一起运行，在使用者眼中，这种创建刚刚开始。如果有错误，所有的关键数据都将被存储起来。 这种构建引擎以域服务的一部分的形式传输，用以帮助客户。唯一真正要修改的是使构建引擎适应每个客户的独特的JCL和数据库标准。这个构建引擎也是上面两个案例实现中的一部分。 在本地传输案例中，ClearCase z/OS 扩展解决方案使其能利用其它的 Rational 解决方案，像ClearCase Multisite。本地运输计划把他们的部分研发迁移到海外去，同时要在两个地方的维护开发过程。考虑到它的构建过程，它允许非常底层的管理，因为一旦利用一个构建引擎，唯一的维护就是：如果要改变z/OS的基础结构，应该提供新的目标数据库。当对编译器进行更新时，也要增加新的数据库。如果要增加一个新的元素类型，这个构建引擎只在z/OS开发过程中增加了新的开发语言时才被修改。 通过允许z/OS开发团队运用GUI工具去帮助他们的开发过程，利用 ClearCase diff/merge 工具， 以及代码回归测试，以上两个案例的实现中添加了额外价值。 运用项目级属性允许在执行周期中具有灵活性。虽然在本地运输案例中希望有一个固定的执行周期，如果将来有需要的化，可以允许在项目级属性中增加z/OS基础结构到执行周期中去。例如，他们需要增加 QA 能力，他们可以很容易的动态的在项目级属性上改变迁移路径。唯一的限制是创建支持它的z/OS基础结构。 C部门也看到了跟国内运输一样的价值，另外还有个好处是：利用ClearCase做并行开发，还可以根据需要灵活地改变迁移路径。 在z/OS环境下，改变不是件小事，但ClearCase使其容易管理。理解这个新过程的最好方法是把ClearCase看作一个对 z/OS的接口。就像 Interactive System Productivity Facility （ISPF）是一个接口一样，ClearCase 作为一个传递到环境的机制。它允许z/OS开发团队使用 Clearcase 的益处，并用GUI工具在过程中帮助他们。单一的存储方案允许对所有的开发使用相同的过程，不管是基于分布式的环境，还是基于/OS平台。它还帮助我们巩固已有的多种CM解决方案，并从当今以主机为基础的复杂环境中汲取教训。 1PJCL代表“伪工作控制语言”，是Clearcase z/ox扩展独有的。它与普通的工作控制语言相似，并拥有其它CM解决方案，像CA-Endevor的SCL软件控制语言和Serana的ChangeMan ISPF框架。
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
