利用 Rational ClearCase ClearMake 构建高性能的企业级构建环境

转载地址:http://www.ibm.com/developerworks/cn/rational/r-cn-clearmakebuild/

构建管理是 IBM® Rational® ClearCase 产品的一个重要模块,它将软件产品的构建和软件开发配置管理进行无缝衔接,方便统一管理,而且还提供了并行和分布式构建,为构建一个高效稳定的构建环境提供了便捷。在 ClearCase 构建管理中有两个构建应用 ClearMake 和 Omake。ClearMake 可用于 Unix、Linux 和 Windows 平台上基于 makefile 的构建客户,Omake 主要适用于那些需要和 Windows 上构建程序兼容的客户。本文主要围绕着 ClearMake 来介绍如何实现高性能的企业级构建环境。

0 评论:

汪 维敏, 软件工程师, IBM

李 雪鹏, 软件工程师, IBM

2010 年 9 月 28 日

  • 内容

在 IBM Bluemix 云平台上开发并部署您的下一个应用。

现在就开始免费试用

随着敏捷开发和持续集成的流行,软件产品基本上要求每日构建,这对软件企业的构建环境来说是一个很大的挑战。一个高效稳定的构建环境对提高软件开发效率起到越来越重要的作用。对很多软件开发团队来说,构建效率是他们最为关注的方面,本文就如何提高构建效率展开讨论,并给出一些具体的方案。

构建管理是 IBM® Rational® ClearCase 产品的一个重要模块,它将软件产品的构建和软件开发配置管理进行无缝衔接,方便统一管理,而且还提供了并行和分布式构建,为构建一个高效稳定的构建环境提供了便捷。在 ClearCase 构建管理中有两个构建应用 ClearMake 和 Omake。ClearMake 可用于 Unix、Linux 和 Windows 平台上基于 makefile 的构建客户,Omake 主要适用于那些需要和 Windows 上构建程序兼容的客户。本文主要围绕着 ClearMake 来介绍如何实现高性能的企业级构建环境。

构建是实现持续集成的关键

持续集成(Continuous Integration)可以有效提高软件产品的发布频率,它也是实现敏捷开发的一种重要途径,持续集成就是把软件产品的构建,安装配置和部署,自动化测试,测试结果分析报告,构建结果打包分发这一系列过程串联起来,形成一个自动化过程,不需要人工干预。这个自动化过程通常夜间执行,第二天早上就可以看到最新开发功能的测试结果,如果没有测试错误出现,还可以获得最新的产品安装包,这可以有效地提高软件产品的开发和测试效率。

下面这个图描述了一个典型的持续集成平台:

图 1. 一个典型的持续集成平台

这个平台有以下几部分组成:

  1. 构建服务器,用来构建产品
  2. 部署服务器,对构建结果进行安装,配置和部署,为自动化测试做准备
  3. 自动化测试环境,触发和执行自动化测试脚本
  4. 测试结果分析报告服务器
  5. 产品安装包分发服务器,开发和测试人员,客户可以从这个服务器获取安装包

所有这些服务器是通过 IBM® Rational BuildForge 产品连接起来,它们之间如何相互通信具体请参考有关 BuildForge 的文章。

从图中可以看到,软件产品的构建是这个平台的关键,其它的过程都依赖于软件构建的结果,软件构件的效率和稳定性直接决定着持续集成平台的可用性。

回页首

ClearCase 的构建管理简介

构建管理是 ClearCase 的一个重要模块,在 ClearCase 中有两个构建应用 ClearMake 和 Omake,这两个应用都是独立的可执行文件,不是 cleartool 的子命令,它们所使用的 makefile 文件兼容其它的构建工具所使用的 makefile。

术语和概念

以下几个术语是深入理解和使用 ClearMake 的基础,是必须要掌握的概念。

派生对象 DO(Derived Object):构建所生产的目标文件,例如 obj 文件,库文件

配置记录 CR(Configuration Record):记录关于 DO 的生成过程,包括构建环境信息,构建脚本,代码的版本,构建时间,输入和输出等大量信息,它还可以帮助定位一些构建错误。

审计(Audit):只适用于动态视图,在构建过程中受 MVFS 监控,为新生成的 DO 创建 CR,并使 DO 和 CR 关联起来。

构建避免(Build Avoidance):尽量使用已存在的 DO,避免创建新 DO 的能力。

配置查询(Configuration lookup):在当前视图和其它视图中比较候选 DO 的 CR 来决定是否可以使用当前视图和其它视图中 DO,以此来决定是否需要重新构建来生成新的 DO。配置查询还有一个非常形象的称呼叫购物(shopping),如果把动态视图比喻成商铺,那么在多个商铺中去寻找所需的 DO 商品的过程就和 shopping 的过程一样。

Wink-in 和 Promotion:下图描述了 Wink-in 和 Promotion 的整个过程。在视图 1 中,构建生成了 DO util.obj, 这时 CR 和 util.obj 存储在视图 1 中。当用户在视图 2 发起构建时,这时配置查询(shopping)就发生了,构建会在视图 2 和视图 1 中查询是否有可用的 DO,如果找到了就不会重新构建来生成新的 DO,而是引用已经存在的 DO,这种能力就是构建避免能力。构建一旦在视图 1 中找到想要的 DO,会导致视图 1 中的 DO 和 CR 被拷贝到 VOB 中,这个拷贝过程叫做 promotion,这时,视图 1 中的 DO 状态从 unshared 变成 shared。视图 2 会创建一个指向 VOB 中 DO 的连接来引用视图 1 中 util.obj,这个过程叫 Wink-in。

图 2. Wink-in 和 Promotion 的整个过程

ClearMake 构建的优势

ClearMake 相对其它的构建产品有着以下的优势:

  1. 可以和 ClearCase 的配置管理无缝衔接,从 VOB 中获取所需的代码版本进行构建,并将构建结果(DO 和 CR)检入(Check in)VOB 中,为构建结果提供多版本管理。
  2. 构建具有审计功能(仅适用于动态视图),不仅为 DO 生成 CR,还将它们关联起来。
  3. 创建共享 DOs,使相同或者不同构建机器上的多个动态 view 共享构建目标文件,避免重复构建,提高了构建效率。
  4. CR 提供了大量的构建信息,可以用 catcr 命令来查看某个 DO 的 CR 信息,在这些信息中,可以看到构建所用的源代码版本,构建语句,构建环境等信息,还可以用这些信息进行构建跟踪,错误分析。
  5. 支持并行和分布式构建,这是很多其它构件产品所不具备的功能,能极大地提高了构建效率。

正是因为 ClearMake 具有这些优势,为构建企业级的高性能构建环境提供了更多的选择。它不仅能极大地提高构建效率,提供更灵活的构建方式,而且能提供构建跟踪和构建错误分析的能力。

回页首

如何实现高性能的构建环境

对很多软件开发团队来说,构建效率是他们最为关注的方面,这直接影响软件产品的开发效率,下面将介绍 5 种方法来提高构建性能,其中并行构建和分布式构建是 ClearMake 所独有的两种方法。

1) 正确选用快捷(Express)构建和审计(Audit)构建

通常情况下,在 ClearCase 的动态视图中执行构建操作,这时的构建是具有审计功能的,也就是说除了生成 DO,还会创建和 DO 相关的 CR,这时的构建受到 MVFS 监控。而且创建的 DO 包括两部分:DO 文件本身和位于 VOB 中的 Catalog entry。这意味着创建 DO 的时候要先 lock VOB,然后写 VOB,这是比较慢的。而且因为 lock VOB,所以影响 VOB 的正常使用。

Express 构建也创建 DO 和 CR 但是,但不在 VOB 中创建 Catalog entry,没有 lock VOB 和写 VOB 的动作,这有效地提高了构建速度,但是构建生成的 DO 的状态是 non-shareable,就是说这个 DO 不能被其它的视图共享,因为在进行配置查询的时候不能从 VOB 的 Catalog entry 找到。也可以用 winkin 和 view_scrubber –p 将 non-shareable DO 转成 shared DO。请注意 unshared,shared 和 non-shareable 的区别。

当用命令行创建动态视图的时候可以指定 –sha/reable_dos 或者 –nsh/areable_dos 参数来决定在这个视图中的构建是 Express 构建还是审计构建。

当用户使用 GUI 来操作 ClearCase 时,可以在 view 的属性界面中指定那种构建:

图 3. 在 view 的属性界面中指定那种构建

2) 使用远程 DO pool

在一个企业级的构建环境中,构建的频率是相当高的,也就是说 DO 的生成和删除频率是很高的,这对构建服务器的 I/O 的吞吐量要求比较高,这很可能成为效率瓶颈。默认情况下,DO 是存储在 VOB 物理存储根目录下的 d 目录下,也就是 DO pool 中,为了解决 I/O 吞吐性能瓶颈,可以把 DO pool 转移到一台独立的服务器上,可以用 chpool 命令来实现这个转移,然后在创建 DO 的时候使用新建的 DO pool。这样针对 DO pool 的 scrubber 任务也发生在这台独立的服务器上,这也可以减轻 VOB 服务器的负载。

3) 使用多个构建 session

当在 view 上下文中执行 ClearMake 命令的时候就启动了一个构建 session,这个构建 session 也可以有一些子 session,ClearMake 支持嵌套构建的功能,每一个构建 session 都有自己独立的审计功能。当在执行一个比较大的构建任务时,可以启动几个构建 session,每个 session 承担一部分任务,最后合并构建结果,以此来提高构建效率。例如:要构建一个比较大的目录 \lib,在这个目录中有三个子目录 \lib\vob, \lib\view, \lib\db,这种情况下可以启动 3 个构建 session,一个构建 vob 目录,一个构建 view 目录,第三个构建 db 目录。三个子目录构建完成了就等于 lib 目录构建完成了。

4) 使用并行构建

ClearMake 还支持并行构建,所谓的并行构建就是当执行 ClearMake 命令的时候,系统会自动启动指定数量的进程来共同完成这个构建任务,可以用 ClearMake –J 参数来指定进程的数量。这个数量的确定应该根据构建机器的负荷来确定,过多或者过少都不利于性能的提高。所有的进程都是由 ClearMake 来创建启动,这些进程间如何划分任务和协作不受人工干预,完全由 ClearMake 程序控制。

5) 使用分布式构建

所谓分布式构建,就是在并行构建的基础上,将自动启动的进程分布在不同的构建服务器上,以此来提高每个构建进程的吞吐量,由于不同的构建服务器的计算能力是不同的,还可以通过配置以下文件和环境变量来达到负载均衡:

/var/adm/atria/config/bldserver.control
$HOME/.bldhost
$CCASE_HOST_TYPE

回页首

应用举例

我们在这里假设读者已经是 ClearCase 的高级用户,对 ClearCase 的网络拓扑结构,部署都非常熟悉。但是目前的构建环境还是采用传统的方式,利用自己编写的 Makefile 文件来构建整个项目。下面就将详细介绍如何利用 ClearMake 来搭建一个高性能的企业构建环境。

1) 典型的 ClearCase 网络拓扑结构

图 4. 典型的 ClearCase 网络拓扑结构

上图是一个典型的 ClearCase 网络拓扑结构。源代码都放在 VOB 服务器上,所有的开发机器都指向 Register 服务器。如果采用传统的构建方式,每个开发人员都会在自己的机器上进行构建,这样效率比较低下,一些共用的二进制文件也无法共用。特别是在敏捷开发模式下,无法达到每天都构建一次的目的。

2) 利用 ClearMake 搭建的构建环境拓扑结构

为了充分利用 ClearMake 的优势,我们还需要额外的两个服务器,一个是 DO VOB 服务器,用来存放构建好的 DO 文件。这些文件不是按照版本增量来进行存放的,所以空间增长量会很快,需要准备一个磁盘空间很大的服务器,并且需要经常删除一些不需要的 DO 文件,在下一节中将详细介绍这个服务器的用法和作用。另外一个是构建服务器,用来给各个开发人员做构建,也可以让产品发布人员在晚上用来构建整个产品,这样就可以方便测试人员随时跟进进度。这个服务需要性能比较好,最好是多核配置的服务器,这样可以启多个进程来构建整个产品。

在准备好这两个服务器以后,在上面安装上和 Register 服务器同版本的 ClearCase,然后指向 Register 服务器。构建服务器上需要使用动态视图,这样能最大发挥 ClearMake 的优势。

图 5. 添加了两个服务器以后基于 ClearMake 的构建环境

上图就是添加了两个服务器以后基于 ClearMake 的构建环境。Do VOB 服务器将用来存储在构建过程中,各个开发人员所共用的 Do 文件。开发人员可以在自己的开发机器上进行构建,也可以在构建服务器上进行构建

3) DO VOB 服务器

首先,在 DO VOB 服务器中划出一部分空间来作为源代码 VOB 服务器的远程 DO pool。开发人员构建出来的 DO 文件通过 Promotion/Wink-in 操作存储到这个远程的 DO 服务器上,以达到共享 DO 的目的,而且能获得更好的 I/O 吞吐量,以此来提高构建效率。由于这个存储库会快速的膨胀,所以管理员需要经常定期的 scrubber。

在一个大的项目中,构建通常会依赖大量的共享库和第三方的库,这些库包括动态链接库,静态库和可执行文件,它们通常不会发生变化,但是每次构建都依赖它们,它们被使用的频率非常高,所以需要把这些库文件放到 DO VOB 服务器中。开发人员在构建整个产品或着某个组件的时候就可以直接用这些已经存在的 DO 文件,提高构建效率。DO VOB 尽量不要和源代码 VOB 放在一个服务器上,因为这个 VOB 的增长速度非常快,需要经常的清理。而且这个 VOB 最好是采用 ClearCase base 的模式来进行管理 , 这样在清理的时候会很方便。DO VOB 应该有严格的权限控制不能让开发人员随意地把自己的 DO 放上去,因为这些 DO 都是一些二进制文件,CC 无法按照增量的方式来保存,必须全部拷贝保存。如果随意的上传自己的构建好的 DO,会很快占满磁盘空间。另外一方面,一些未经过测试的 DO 可能会影响他人的正常构建过程。一般是由负责整个产品构建的人来管理,控制这个 DO VOB。

4) 配置并行构建环境

ClearMake 支持并行构建,可以在一个机器上起多个进程来同时构建,这样可以大大的节省构建时间。这里就具体介绍下如何进行并行构建和一些注意事项:

ClearMake 通过两种方式来控制并行构建进程的数目,一个是环境变量 CCASE_CONC,一个是通过命令行 -J 指定参数。ClearMake 启动的并行构建的数目最大不会超过这里指定的数目。在设置并行构建数目的时候要根据系统的负荷来设置。

在使用并行构建的时候要注意一种情况,在构建某些文件的时候,虽然没有依赖关心,但是由于某种原因不能进行并行构建。比如,有的文件在构建的时候会产生一些中间文件,之后会马上删除,在非并行构建的时候不会有问题,可以产生同名的中间文件,不会影响后面的构建过程。但是在并行构建的时候,这些同名的中间文件会互相影响。可以针对某些特殊的文件停止使用并行构建。在构建文件中加入 .NOTPARALLEL,就可以对指定的文件不进行并行构建。比如下面:

.NOTPARALLEL: %.a
.NOTPARALLEL: x.c y.c

第一句表示,所有 .a 文件不进行并行构建。第二句表示,对 x.c 和 y.c 文件不进行并行构建。但是对 .a 文件和 x.c 或者 y.c 还是可以进行并行构建的。

5)使用 ClearMake 来构建你的产品

当完成以上配置以后,开发人员就可以利用原有的 Makefile 文件进行构建了。ClearMake 本身并没有编译,构建功能,它会根据 Makefile 文件来构建产品,调用 GCC 等编译器来构建产品。开发人员可以在自己的开发流建好自己的视图,然后调用 ClearMake 来进行构建:

.clearmake –f Makefile –J 5

该命令调用当前目录下的 Makefile 文件,启 5 个进程同时构建整个产品。ClearMake 还可以利用构建选项文件来定义一些宏变量。我们推荐可以把一些临时的宏变量(比如 CFLAGS=–g,UNIX 上带调试参数的选项)写入一个构建选项文件中,然后在构建的时候指定该文件。

.clearmake –f Makefile –A /var/tmp/option

回页首

总结

综上所述,ClearCase 的构建模块提供了一套独特的理念和机制来实现高性能的企业级构建环境,其中诸多概念是掌握 ClearMake 或者 OMake 的基础,例如:DO,CR,审计,构建避免,配置查询,shopping,promotion 和 wink-in。除此之外我们还要理解 DO 的三个状态的区别:unshared,shared 和 non-shareable。在此基础上来掌握提高 ClearMake 构建性能的 5 个方法:正确选用 express 还是 audit 构建,使用远程 DO pool,使用多个构建 session,使用并行和分布式构建。最后给出了实际使用中的典型的网络拓补结构,并讨论一些实际使用中的细节问题和注意事项。所有的这些概念,机制和方法为构建一个高性能的企业级构建环境提供了便捷,为实现持续集成奠定了基础,最终提高了软件开发和测试的效率,增加了软件发布的频率,缩短了软件开发的周期。

时间: 2024-10-05 05:41:38

利用 Rational ClearCase ClearMake 构建高性能的企业级构建环境的相关文章

【读书笔记】2016.12.10 《构建高性能Web站点》

本文地址 分享提纲: 1. 概述 2. 知识点 3. 待整理点 4. 参考文档 1. 概述 1.1)[该书信息] <构建高性能Web站点>: -- 百度百科 -- 本书目录: 第1章 绪论 1.1 等待的真相 1.2 瓶颈在哪里 1.3 增加带宽 1.4 减少网页中的HTTP请求 1.5 加快服务器脚本计算速度 1.6 使用动态内容缓存 1.7 使用数据缓存 1.8 将动态内容静态化 1.9 更换Web服务器软件 1.10 页面组件分离 1.11 合理部署服务器 1.12 使用负载均衡 1.1

HAProxy + Keepalived + Flume 构建高性能高可用分布式日志系统

一.HAProxy简介 HAProxy提供高可用性.负载均衡以及基于TCP和HTTP应用的代 理,支持虚拟主机,它是免费.快速并且可靠的一种解决方案.HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理. HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接.并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上. 二.Keepalived简介 它是一个基于VRRP协议来实现的WEB服务高可用方案,

千呼万唤始出来!《高性能Linux服务器构建实战Ⅱ》出版在即

经过近2年的酝酿,几个月的修正,<高性能Linux服务器构建实战Ⅱ----系统安全.故障排查.自动化运维与集群架构>一书出版在即,马上就要与读者见面了. <高性能Linux服务器构建实战Ⅱ----系统安全.故障排查.自动化运维与集群架构>仍 然沿用了<高性能Linux服务器构建实战---运维监控.性能调优.集群应用>的写作特点:实战.实用.通俗.易懂的特点,而在内容上更加实战化,从运 维的多个方面以近似真实的环境介绍运维工作中的各个方方面面,与第一本书不同的是,此书新增

构建高性能web站点

以下为阅读<构建高性能web站点>郭欣 著 第一章的重点总结 1.等待的真相 a) 在用户等待的时间里,大概发生了以下几部分时间: i. 数据在网络上传输的时间:包括两个部分,浏览器端主机发出请求经过网络到达服务器的时间,服务器回应数据经过网络到达浏览器主机的时间.也称为响应时间,他的决定因素主要包括发送的数据量和网络带宽.站点服务器处理请求并回应数据的时间- ii. 站点服务器处理请求并生成回应数据的时间.主要消耗在服务器端,包括非常多的环节,我们一般用"每秒处理请求数"

linux运维好书《高性能Linux服务器构建实战Ⅱ》已出版发售,附封面照!

经过近2年的酝酿,几个月的修正,<高性能Linux服务器构建实战Ⅱ----系统安全.故障排查.自动化运维与集群架构>一书出版在即,马上就要与读者见面了. <高性能Linux服务器构建实战Ⅱ----系统安全.故障排查.自动化运维与集群架构>仍 然沿用了<高性能Linux服务器构建实战---运维监控.性能调优.集群应用>的写作特点:实战.实用.通俗.易懂的特点,而在内容上更加实战化,从运 维的多个方面以近似真实的环境介绍运维工作中的各个方方面面,与第一本书不同的是,此书新增

如何构建高性能,稳定SOA应用之-负载均衡-Decoupled Invocation

当我们在为一个软件设计架构的时候,我们不仅仅要确保所做出来的架构要满足系统的业务需求,更加要确保做出来的架构要满足可维护性,安全,稳定性的非业务行的需求. 另外一个非常重要的非功能性需求就是性能.性能涉及到很多方面的关注点,例如吞吐量,延迟等.SOA的很多的设计原则和一些指导从来没有告诉我们如何去解决SOA中遇到的性能问题,因为SOA的关注点不在这里,其实SOA天生就是会导致很差的性能的:因为SOA涉及到了分布式,这就决定了它有很多不得不要的延时和不同的层之间的通信问题. 任何问题,都有其对应的

构建高性能JavaScript应用

前端性能优化准则: 一.减少http请求. 措施:合并小图片,css控制背景图.合并CSS,合并JS 二.使用CDN(Content Deliver Network 内容分发网络)发布静态资源. 三.启用压缩组件. response header:Content-encoding request header:Accept-encoding 四.添加Expires响应头. response header:Expires(指定过期时间) 缺点:1.需要指定具体的过期日期,时间到后需要重新指定.2.

爬虫—使用协程构建高性能爬虫

使用协程构建高性能爬虫 一.简介 在执行一些 IO 密集型任务的时候,程序常常会因为等待 IO 而阻塞.比如在网络爬虫中,如果我们使用 requests 库来进行请求的话,如果网站响应速度过慢,程序一直在等待网站响应,最后导致其爬取效率是非常非常低的.为了解决这类问题,本文就来探讨一下 Python 中异步协程来加速的方法,此种方法对于 IO 密集型任务非常有效.如将其应用到网络爬虫中,爬取效率甚至可以成倍地提升.本文使用 async/await 来实现,需要 Python 3.5 及以上版本.

构建高性能数据库缓存之redis主从复制

一.什么是redis主从复制? 主从复制,当用户往Master端写入数据时,通过Redis Sync机制将数据文件发送至Slave,Slave也会执行相同的操作确保数据一致:且实现Redis的主从复制非常简单. 二.redis主从复制特点 1.同一个Master可以拥有多个Slaves. 2.Master下的Slave还可以接受同一架构中其它slave的链接与同步请求,实现数据的级联复制,即Master->Slave->Slave模式: 3.Master以非阻塞的方式同步数据至slave,这将