简介一般来说，在敏捷开发模式下，整个开发周期被分割成多个短期的迭代（典型的为二到十二个星期）。在每个迭代的开始，开发团队与客户共同决定本迭代所要实现的需求。可能每个迭代周期开始时都有很多需求，不能在一个迭代里面实现，所以需要按一定的优先级顺序来决定先实现哪些需求。在一次迭代中没有被实现的需求被保留下来，作为一个需求库，在下一个迭代开始的时候开发团队和客户会再次选择高优先级的需求。迭代如此循环。如图 1 所示。 图 1. 敏捷开发模式示意图 敏捷开发模式具有两个非常重要的特点。一个是每个迭代结束应该有一个可展示的“产品”（可能这个产品并不完善）提供给客户，客户基于当前的“产品”提出新的需求或者变更。这些新需求和变更和上个迭代留下的需求一起进入下个迭代。另外一个特点是在每个迭代期间，开发人员只致力于当前迭代的需求。这样做的意图是，保持设计的简单，并且防止不必要的特性膨胀。代码还是不断地集成的，并频繁地以很小的单位进行实现、测试及提交，这可以利用在提交时刻调用的自动化构建过程来检查集成错误。 想要实现上述这些最佳实践，一个轻量级、快速响应、功能全面简洁并且兼容性强的软件构建和版本管理工具必不可少。 而 CCRC 7.1 就是一个满足上述需求的软件构建和版本管理工具。下面首先介绍 CCRC 7.1 具有哪些新功能，然后介绍如何基于 CCRC 7.1 实现高效的敏捷开发。 CCRC 7.1 中面向敏捷开发的新功能顾名思义，ClearCase Remote Client 是 ClearCase 的一个远程客户端。在版本控制方面，它延用了 ClearCase 的整套概念，基本工作流程也是基于 ClearCase。关于这些基本信息，请参照 CCRC 7.0 及之前的版本或者 ClearCase 相关文档，这里不再赘述。作为一个远程客户端，CCRC 有如下优点。
为了适应敏捷开发，CCRC 7.1 版本增加了许多新功能。下面对这些新功能进行简单介绍。 简洁导航器视图在 CCRC 7.1 中，所有 ClearCase 相关的资源都通过一个导航器视图以层次化格式显示。用户可以非常简单快捷的修改其中的任何内容。图 2 更直观的表示了这种显示方式的效果。 图 2. CCRC 7.1 中的 ClearCase 导航器视图 从图中可以看到，ClearCase 导航器视图下主要有两项，一项是本地视图，列出所有的本地静态视图。另外一项是服务器信息，该项信息下面显示相应服务器上的 ClearCase 和 ClearQuest 信息。ClearCase 下面显示了 ClearCase 服务器上的组件 VOB 及其属性以及项目 VOB 及其属性。ClearQuest 下面显示了 ClearCase 服务器上 ClearQuest 的连接信息。 暂挂更改视图一般来说，一个开发团队里有多个开发人员。在一开始他们是独立工作的，当开发工作进行了一个阶段之后（比如一天），他们要集成每个人的开发工作作为统一代码资源，然后每个开发人员把统一的代码资源引入到自己的工作空间。如图 3 所示 图 3. 开发阶段—集成和同步 这里涉及到两个阶段，面临一个问题。两个阶段分别是交付和同步，面临的问题是冲突。交付是指将各个开发人员的工作集合起来，生成统一代码资源，这里可能会碰到不同的开发人员的内容冲突。同步是指开发人员将统一代码资源整合到自己的独立工作空间，这里也可能会碰到内容冲突的问题。 很多的版本控制管理软件处理冲突的方法就是先软件自动整合，然后如果需要就请求人工干预。但是在软件自动整合之前，用户并不能看到即将整合的内容到底是什么。如果内容不是用户想要的，或者内容存在问题，在软件自动整合之后，就只能选择回滚操作。这种方式很可能浪费时间。 CCRC 7.1 提供了一个查看变更的暂挂更改视图，所谓“暂挂”，就是待解决。相对于本地工作空间来说，暂挂更改有三种类型，输入变更表示只有其它工作空间对文件做了修改，输出变更表示只有本地工作空间对文件做了修改，冲突变更表示本地和其它工作空间都对文件做了修改，并且有冲突的地方。暂挂更改视图就是要根据一定的规则将这些变更显示出来。 我们知道，ClearCase 支持两种工作模式，一直 Base ClearCase，只需要 ClearCase 进行版本管理。这种模式下文件的变更不与活动相关。所以在这种模式下暂挂更改视图是按照组件来分组显示的。如图 4 所示。 图 4. 暂挂更改视图—按文件夹分组 ClearCase 的另外一种工作模式是 UCM，这种模式下文件的变更与活动相关联。所以这种模式下暂挂更改视图是按照活动来分组显示的。如图 5 所示。 图 5. 暂挂更改视图—按活动分组 在暂挂更改视图中，上下文菜单非常丰富。其中常用的有两种，一种是预览变更，另外一种是解决变更。使用非常方便。 暂挂更改视图从显示上就体现了它的简洁性，不同的工作模式采取不同的显示方式，另外，工具栏还提供是否显示某种变更的工具（比如只显示冲突变更，或者只显示输入变更等）。更重要的是，丰富的上下文菜单是的用户处理变更方便快捷。 高级交付 / 同步选项在敏捷开发过程中交付和同步是比较频繁的动作，所以需要有方便快捷的方式。CCRC 7.1 除了提供默认的交付 / 同步操作之外，还提供了高级交付 / 同步选项。由于 Base ClearCase 不支持视图下的交付 / 同步操作，所以这里所说的交付 / 同步操作都是针对 UCM 视图的。针对 Base ClearCase 模式，可以使用暂挂更改视图或者 ClearCase 合并查找工具完成交付 / 同步功能。 首先介绍高级交付选项。在导航图内选择一个需要交付的视图，打开右键菜单，选择 Deliver->Advanced。弹出对话框如图 6 所示。 图 6. 高级交付 这个对话框主要分两部分，一部分是交付目标流和视图信息，可在交付前进行修改。另外一部分是需要继承的活动以及当前被检出或者 Hijack 的文件。可以选择交付哪些活动。另外对被检出或者 Hijack 的文件，可以选择检入或者回滚。如果保持检出或 Hijacked 状态，交付前会提示说有处在检出或 Hijacked 状态的文件，它们将不会被交付，用户可以选择继续也可以选择放弃。 其次介绍高级同步选项。打开方式与高级交付非常相似，即在视图右键菜单里选择 Rebase -> Advanced. 弹出对话框如图 7 所示。 图 7. 高级同步 如图所示，这个对话框也是有两个部分，上面是同步流、视图信息。下面供用户选择集成流的基线。有很多种选择，用户可根据自己的习惯来使用。另外，如果当前视图下存在检出或 Hijacked 状态的文件或文件夹，会被列出来。至于此时是不是可以同步，则要看项目策略的设置。各个团队有自己的偏好。 丰富的“编辑配置”视图使用编辑配置视图用户可以转入或卸载资源。在 CCRC7.0 及其之前的版本中，用户每次只能装入一个 VOB。如果想装入多个 VOB，唯一的办法就是多次重复操作。而在 CCRC7.1 的编辑配置视图下，用户可一次性装入多个 VOB。另外，该视图还提供 VOB 过滤功能。比如只显示公用 VOB 或私有 VOB，这对具有多个 VOB 的用户来时是非常有用的。 另外，也可通过编辑配置视图来编辑版本选择规则。在 CCRC7.0 及其之前的版本中，用户需要手动输入所有的版本选择规则，无法重用已有视图的版本选择规则。而 CCRC7.1 提供了这个功能，更方便了用户的使用。 与 ClearQuest 集成UCM 是 IBM Rational 的一个非常成熟的统一变更管理解决方案。CCRC 7.1 自然是支持这一解决方案的。但是其实如果用户不能在客户端直接查看存放在 ClearQuest 里面的活动，而需要转到 ClearQuest 的某个客户端去的话是非常不方便的。CCRC 7.1 的集成了 ClearQuest，使得用户可以直接在 CCRC 里面查看活动，另外在进行检入检出等操作的时候可以随时创建活动。这个功能使得用户无需做任何界面切换，非常方便。 基于 CCRC 7.1 的敏捷开发模式从图 1 我们看到敏捷开发模式具有两个重要特点。即在开发期间的可展示“产品”以及不断变化的需求。而这两个特点都强调一个属性，那就是敏捷。在对于敏捷模式的支持上，CCRC 7.0 及之前版本和 CCRC 7.1 略有不同。本节将首先比较 CCRC 7.1 与 CCRC 7.0 及之前的版本下的敏捷开发模式，然后介绍基于 CCRC 7.1 的敏捷开发模式的工作流程。 两种开发模式比较在基于 CCRC 7.0 及之前版本的开发模式下，每个开发人员在私人流 / 分支（流是 UCM 模式下的概念，分支是 Base ClearCase 下的概念），完全通过与集成流 / 分支的交付和同步操作来取得与其他开发人员的联系。如图 8 所示。 图 8. 基于 CCRC7.0 及之前版本的敏捷开发模式 由于 CCRC 7.0 及之前版本并不提供暂挂视图之类的简便的变更解决功能，所以在图 8 的模式下开发人员之间的沟通变得比较困难，而敏捷开发模式最强调的一点就是沟通快捷顺畅。 基于 CCRC 7.1 的开发模式在之前的开发模式上做了改进。如图 9 所示。 图 9. 基于 CCRC 7.1 的敏捷开发模式 图 9 所示的开发模式与图 8 所示的开发模式最大的不同在于，新的模式下开发人员是在共享流 / 分支上工作，而旧的模式下开发人员是在私人流 / 分支上工作。在这种模式下，再加上 CCRC 7.1 的新功能，敏捷开发将会进行的非常顺畅。下面本文将会通过该模式的工作流更进一步说明 CCRC 7.1 对敏捷开发的支持。 基于 CCRC 7.1 的敏捷开发工作流程通过图 3 可以看到，敏捷开发的基本流程就是工作人员在开发流 / 分支上工作，然后把工作内容交付到集成流 / 分支上。另外重新开始新一轮开发之前需要从集成流 / 分支上同步开发流 / 分支。为了把这个工作流程更清晰的与 CC 中流 / 分支的概念联系起来，图 10 以流 / 分支为参照物展示了敏捷开发的基本流程。 图 10. 敏捷开发流 / 分支结构图 注：圆圈里面的数字表示版本号。 竖虚线表示有多个未显示版本号 横虚线表示有多个未显示共享开发流 / 分支 很显然，开发人员开始工作的时候需要这个结构已经存在或者可以自动生成，那么谁来完成那些初始化的工作呢？在共享开发流 / 分支上工作时，谁来负责做交付和同步的工作呢？什么时间做这些工作呢？集成流 / 分支上的统一代码资源有什么人维护呢？如果能回答这一系列问题，基于 CCRC 7.1 的敏捷开发工作流程就显而易见了。 为了方便起见，本文假设某个开发团队有如表 1 所示的角色分配。当然，每个团队都有自己的情况，这里只是给出一个比较常见的分配方式。 表 1. 团队角色分配
这里，小组长及其组员在开发中是在一个共享流 / 分支上工作的。 经过角色分配，基于 CCRC 7.1 的敏捷开发工作流程就呼之欲出了。图 11 以简洁的方式描述了这个流程。 图 11. 基于 CCRC 7.1 的敏捷开发工作流程这个似乎看起来非常简洁。那么每个步骤里面都需要做哪些工作呢？CCRC 7.1 又是怎样通过它的新功能使得这些工作变得非常快捷方便呢？下面将逐步介绍每个步骤的细节。 初始化、配置环境：这个步骤包括搭建 ClearCase 相关的服务器，创建 VOB，项目等。具体请参考 Rational ClearCase7.1 Infocenter（参见参考资料）。本步骤结束后，已有代码资源应该具有主流 / 分支版本。 创建开发流 / 分支、创建开发视图：这两个步骤合起来的目的就是要创建开发工作空间。其实在创建开发视图的时候可以自动创建开发流 / 分支。之所以把这两个步骤分开，是考虑到开发环境中可能有多个 VOB，并且有一个管理 VOB，所有的流 / 分支等元数据都存放这个管理 VOB 内。这种情况应该独立创建开发流 / 分支。在 CCRC 7.1 的导航图中选择 VOB 所在的服务器 -> Component VOBs -> 某个 VOB -> Branch Types。打开 Branch Types 邮件菜单，选择创建流 / 分支，在弹出对话框中填写相应内容即可。 加入某个项目时默认会创建一个新开发流，如图 12 所示。 图 12. 创建 / 重用开发流如果想创建新流，直接填写 Stream name 即可（注意，流名必须唯一）。若想重新已有流，点击按钮 Stream Options，在弹出对话框 Stream Options 里面选择 Re-use an existing development stream，然后在下拉框中选择一个已有流即可。 在创建 Base ClearCase 视图时，会自动生成默认版本选择规则。如果想修改规则，在视图右键菜单里选择 ClearCase View Configuration，在被打开的试图里选择 Load Rules 页，选择编辑工具，打开 Edit Configuration 对话框，选择 Version Selection Rules，编辑规则即可。 可以看出，在创建工作空间方面，CCRC 7.1 即考虑了多种情况，也为各种情况提供了统一方便的界面。 开发：开发人员进行开发工作。由于多个开发人员共享一个开发流 / 分支，所以在开发过程中应该会频繁的用到暂挂更改视图以查看所在开发流 / 分支上的最新变化。这使得开发人员随时跟进当前开发状态。 交付：经过一段时间的开发工作之后，小组长应该将本开发流 / 分支上的内容交付到集成流 / 分支上。在 UCM 模式下，可使用默认的或者高级交付 / 同步选项，也可以在暂挂更改视图里进行交付操作。在 Base ClearCase 下，可在暂挂更改视图里进行交付操作。 维护交付流 / 分支：各小组将工作内容交付到集成流 / 分支之后，团队领导需要维护集成流 / 分支上的统一代码资源。其中应该包括解决冲突、兼容性等常见问题。另外维护中有一个非常重要的问题，那就是频繁的集成构建会使得每次集成的问题不断积累，最坏的情况可能导致整个代码资源瘫痪。这个问题是敏捷开发团队经常遇到的大难题。持续集成从一定程度上解决了这个问题。本文下一节将介绍基于 CCRC 7.1 的持续集成。 如果某次集成的结果很好，小组领导可能会制作并推荐一个基线供各小组同步。在 CCRC 7.1 里，制作和推荐基线都非常简单。在导航图内的服务器信息下面找到需要制作或推荐基线的集成流 / 分支，选择右键菜单里的创建基线、推荐基线，在弹出对话框中填写相应信息即可。 同步：通过持续集成，前期代码得到基本验证，下一轮的开发工作开始。在开始之前各开发小组应该同步本开发流 / 分支的代码。在 UCM 模式下，可使用默认的或者高级交付 / 同步选项，也可以在暂挂更改视图里进行同步操作。在 Base ClearCase 下，可在暂挂更改视图里进行同步操作。 至此，本文介绍了基于 CCRC 7.1 的敏捷开发流程。之前提到敏捷开发的一个重要的最佳实践，持续集成，下面介绍基于 CCRC 7.1 的持续集成。 基于 CCRC 7.1 的持续集成通过敏捷开发流程里，集成非常频繁。团队领导需要花很多时间来维护集成流 / 分支上的统一代码。而且集成构建非常的繁琐，也会消耗很多时间和精力。持续集成（Continuous Integration）从一定程度上解决了这个问题。下面首先介绍什么是持续集成。然后介绍基于 CCRC 7.1 的持续集成的实现。 持续集成持续集成是敏捷开发的一个最佳实践。它是通过一个自动化的过程来达到自动集成构建和基础测试的目的。Martin Fowler 在他的文章“Continuous Integration”这样定义持续集成：Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day。 我们认为持续集成是一个软件开发最佳实践，其中集成、构建和基础测试依次重复进行。从过程的角度来说，持续集成是一个循环的过程，每个循环包含三个部分：更新集成工作空间、集成构建和反馈。图 13 显示了三个步骤的关系。 图 13. 持续基本集成结构图第一步，版本控制，由版本管理软件完成，比如 ClearCase 7.1。第二步，集成构建。第三步，反馈，可以通过网页或者邮件形式。其中最为关键的就是第二步集成构建。现在已经有很多软件实现了持续集成这个最佳实践，比如 Rational BuildForge。 实现持续集成前面介绍了持续集成的基本概念了结构，本小节将实现基于 CCRC 7.1 的持续集成。 首先来分析需要哪些工具。通过图 13 可以看出，最基本的工具有三个，第一，版本控制工具，这里我们使用 ClearCase 7.1，客户端则使用 CCRC 7.1。第二，集成构建工具，可使用 IBM Rational BuildForge。第三，反馈工具，为了简便起见，本文直接使用网页反馈。在实际使用中，可使用邮件反馈，比如 IBM Lotus Notes。确定了工具后，把它们带入到结构里，不难得到基于 CCRC 7.1 的持续集成的架构图。如图 14 所示。 图 14. 基于 CCRC 7.1 的持续集成的架构图根据上面的架构图，很容易得出基于 CCRC 7.1 的持续集成需要做下面的工作：
下面主要介绍最后的步骤，即如何基于 CM API 编写代码更新程序。 ClearCase 7.1 提供了 CM API，用户可以基于这些 API 来编写一个用户在客户端更新代码的程序。那么，在编写这个程序之前，需要回答下列问题：
下面依次回答这些问题。 代码更新程序的作用就是从客户端发送代码更新的请求给服务器，然后服务器做出响应，最后代码得到更新。根据这个角度，图 15 给出了 CM API 的结构图。 图 15. CM API 的结构图可以看出，CM API 就是通过一层层的 Provider 来处理客户端的更新请求的。 CM API 在 ClearCase 的安装路径下，总共包含 5 个 JAR 文件。如图 16 所示。 图 16. CM API 的位置第一和第二个问题都得到了解决，下面解决第三个问题。 程序的最终目的是要更新代码，在更新之前需要知道更新目标。而所有的更新目标都在静态视图内，所以要想得到更新目标，要先得到静态视图。通过 CM API 架构图可以知道，要想得到任何对象，必须先创建相应的 Provider。那么，很显然，程序的流程如下：
清单 1. 创建 Provider//new an instance of class MyAuthCallback Callback callback = new MyAuthCallback(serverUrl, login, password); //get provider with instance of callback CcProvider provider = (CcProvider) Providerfactory.createProvider(CcProvider, .PROVIDER_CLASS, callback);
清单 2. 获得静态视图//new object of file with the root directory. File file = new File(loc); //the directory is a copy area for a certain snapshot view. StpLocation stplocation = (StpLocation) provider.filePathLocation(StpLocation.Domain.CLEAR_CASE, file);
清单 3. 获得视图内元素//get proxy for resource ControllableResource res = getProxy(loc, provider); //get properties for resource. PropertyRequest prop = new PropertyRequest (new PropertyRequestItem[] (ControllableResource.IS_VERSION_CONTROLLED)); Res = (ControllableResource) res.doReadProperties(prop); //if the resource is under source control, add it into resource list. It will be updated if ( res.getIsVersionControlled()) resourcelist.add(res);
清单 4. 更新目标//update resource View.doUpdate(resourcelist, PropertyRequest.EMPTY); 总结Rational ClearCase Remote Client (CCRC) 7.1 是 ClearCase 7.1 的轻量级客户端，它具有诸多优点，如简洁导航器视图、暂挂更改视图、集合操作、高级交付 / 同步选项以及与 ClearQuest 集成。所有这些优点都使得 CCRC 7.1 非常适合现在流行的敏捷开发模式。本文介绍了基于 CCRC 7.1 的敏捷开发模式工作流程。并提出了基于 CCRC 7.1 的持续集成的实现方法。 |
|
|
来自： 淡茶飘香cl > 《clearcase》
