rational rosa_使用Rational Team Concert管理并行开发
本文中术语和概念的定位
在协作团队环境中进行开发时，通常有必要将不同的开发活动划分为单独的工作流。 这可能是基于功能的（例如，与图形用户界面更改隔离的一组安全增强功能），也可能是与新的开发工作隔离的一组缺陷，以便可以快速将缺陷补丁程序发布到顾客。 创建这种工作分离的原因很多，在许多版本管理系统中，这是通过一系列并行分支来实现的。
在IBM®Rational Team Concert™中，并行开发通过使用几种不同的流来支持。 开发人员完成的工作流到特定的流，并与同一流中其他开发人员的工作集成在一起。 通过使用多个流，开发人员的不同子团队的工作得以分离，直到执行特定活动以集成来自多个流的工作为止。
简而言之，在适当的时候，流使团队能够自动将高度协作的人员的工作与他人的工作进行集成。
本文的目的是通过描述场景和创建该场景的步骤来定义使用Rational Team Concert特性进行并行开发的过程。 所示的模式包括典型团队所需的许多开发方面，但是可以修改过程以支持任何组织和任何开发过程的特定要求。
是“敏捷”吗？
敏捷开发的关键原则之一是频繁集成每个开发人员产生的更改，并不断构建新集成的应用程序代码。 结果，一些敏捷的纯粹主义者可能认为正式分离的过程不在敏捷开发的范围之内。 但是，一些开发工作的规模意味着一个单一的同地团队可能是不可能的。 此外，变更的规模和复杂性可能确实令人生畏，导致需要隔离。 IBM®Agility @ scale™的原则鼓励团队划分，因此将工作分配给不同的团队。
由于团队的实际隔离或任务的复杂性，将一定程度的分离和受控集成引入敏捷开发团队可能是有意义的。 这可以根据位置显示在流中，也可以显示在特定发行版的流中。 当Rational Team Concert将要完成的工作分解为例如通过使用共享Integration流进行集成的一系列功能流时，它们可以为敏捷团队提供支持。
的确，许多敏捷团队都使用免费软件或低成本开发工具，这些工具为单独开发提供有限的支持。 由于功能限制和此类工具中集成的高昂开销，此类工具通常使开发人员无法使用单独的方法。 对于许多敏捷团队来说，Rational Team Concert是一种机制，可以提高他们的游戏效率，并在效率，灵活性和创造力方面将其开发能力提升到一个新水平，这些能力可以在其开发过程中进行设计。
Rational Team Concert可以支持从小型并置敏捷团队到大型分布式团队（包括许多较小的敏捷开发活动子单元）的开发工作。 Scott Ambler在他的博客文章中描述了敏捷团队和纪律敏捷交付方法的一些关键特征（请参阅“ 相关主题”部分）。
- 进化的
- “敏捷策略本质上既是迭代的又是增量的，” Ambler说。 必须允许流结构发展以支持项目的当前需求。 拥有一支了解流，集成和构建过程的团队将确保软件配置管理工具可以在任何时间点支持团队的活动。 在项目开始编写代码之前，不必一定要设计项目的整个并行开发结构，但是所有人都应该理解一些原则。 这些应该包括跨流集成的管理，发布流的控制和安全性，以及对在冲刺期间未完成但留在流或工作区中的工作的管理。
- 高度协作
- 用于共享工作并保持开发人员活动的高度可见性的机制可以将普通的敏捷团队转变为高效的敏捷团队。 对用户进行共享内容的机制教育以及对其他开发人员正在做的事情的了解是避免浪费时间和无效开发的关键。
- 在适当的治理框架内进行自我组织
- 配置管理是一个领域，其中编写了许多过程文档（包括该作者），但很少阅读。 拥有正确级别的治理框架是使开发人员从我们要求他们针对配置管理区域执行的操作中看到价值的关键。 设置一个流程框架，使团队能够理解他们需要提供什么才能将应用程序发布到生产环境中，但是让他们自己决定流程的方式是使团队具有创造力和自组织能力的好方法。 这样的自我组织的团队通常会根据他们正在从事的开发类型，团队的技能和可用的自动化技术而倾向于采用最适合他们的方法。 见链接相关信息对流程模板和自动化框架的更多信息。
Rational Team Concert简介
假定读者总体上对Rational Team Concert和软件配置管理原理有基本的了解。 关于Rational Team Concert和其他紧密相关产品的更多信息可以在Jazz.net的网站上找到。 为了支持本文的读者，本节中包含许多并行开发的关键产品概念和术语。
- 流
- 该流在概念上与大多数其他版本控制系统中的分支相似。 但是，在使用Rational Team Concert时，有一些明显的差异可以启用特定的操作。 流充当更改的收集点，然后可以将更改传递到其他流。 在此处介绍的场景中，流用于将更改收集到逻辑单元中，然后将其传递到另一个流以管理发行版。 由于存在分支的数量，一段时间后，其他版本管理系统中的许多并行开发结构将变得非常难以使用。 在Rational Team Concert流上完成工作之后，可以删除该流，因为所有内容都将被移至另一个位置。 通过这种方式，可以将流视为用于执行工作的临时结构，或者用于保存和记录工作的更永久的结构。
- 变更集
- 在Rational Team Concert中在版本控制下对文件进行更改时，需要对其进行管理和跟踪。 一些版本控制系统在逐个文件的基础上执行此操作，并且内容在一个分支到另一个分支之间逐个文件地合并。 这通常会导致错误，遗忘的内容或文件合并，从而可能导致构建中断或部分完成的工作。 开发人员具有自然的过程，可以将文件更改分组在一起，形成逻辑上构成完整工作单元的集合。 在Rational Team Concert检入过程的一部分中执行此分组任务，在该过程中创建和管理变更集。 然后，在大多数情况下，变更集将与工作项（例如任务 ， 缺陷或故事）相关联 。 这使更改集的上下文可见，并且允许团队成员查看执行的更改以满足工作项的要求。
- 基准线
- 在开发项目的特定时间间隔内，有必要在沙子中隐喻地划一条线，并确定文件内容，这些文件内容共同构成一个稳定的，可发布的软件单元（或版本管理系统中包含的其他有用工作单元）。 Rational Team Concert中使用的识别点是基线。 应用基准可在应用基准时识别存在的文件及其特定版本的内容。 然后，可以将基线用作参考点，以访问特定文件配置。 可以比较基准以显示两个标记的时间点之间存在的差异，从而显示开发人员的活动。
在许多版本控制系统中，基线比较会将差异显示为两点之间已更改的文件列表。 Rational Team Concert可以通过这种方式呈现信息，并且这种方法确实具有一定的价值。 但是，从事开发项目的许多人需要查看在更高的抽象层次上实际发生了什么变化。 如前所述，如果变更集与工作项相关联，则可以使用已完成工作项的列表来表示两个基准之间的差异。 例如，在上一次迭代中完成的35个缺陷和12个故事的详细信息通常可以传达有关发生了什么事情的更多信息，即728个文件在相同间隔内发生了变化。
- 交货
- 术语传递是指将文件更改从开发人员的隔离工作区传输到当前与该工作区关联的流。 传递操作或传递的结果是，新文件或文件的新版本将存储在流中，并且可供与该流关联的其他开发人员使用。 Rational Team Concert将通知其他开发人员新内容的存在，并且他们可以选择适当的时间接受更改。 用户可以切换他们想要向其传递代码的流（如稍后所述），项目管理员可以控制允许谁向特定的流传递内容。
交付过程类似于在其他版本管理系统中从一个分支到另一个分支的合并。 Rational Team Concert的主要优点之一是，它使开发人员能够交付包含与工作项相关联的变更集的工作项。 因此，尽管前面提到的基准比较可以在工作项级别报告，但是实际的开发人员也可以交付操作。
- 用户工作区
- 每个用户都有一个存储库工作区，该工作区已连接到将要交付其工作的流。 当用户对文件进行更改时，编辑后的副本将保存在与存储库工作区关联的客户端沙箱中。 用户完成更改后，将检入文件并将其从客户端复制到存储库中基于服务器的区域。 将该文件收集到用户也已更改的其他文件中的更改集中 。 更改集完成后，用户将其传递到流。
并行开发流
即使当用户使用相同的流（例如，图1中的Feature Stream 1）时，用户之间仍然存在一定程度的分离，并且在他们交付和接受变更时，变更的受控集成如图3所示。
图1.流签入和交付
功能流
此方案的起点是一个团队，该团队希望将他们所做的工作分为两个额外的流，以隔离其活动。 如图2所示。
图2.简单的特征流结构
图2显示了开发人员已将许多变更集交付到的Main Development流。 例如，变更集已在＃1之前交付，而另一个变更集已在图中的＃1和＃2之间交付。 如果在项目内未创建其他流，则团队交付的所有变更集将集成在单个共享流上。 但是，从事此项目的开发团队已决定，团队中的几个开发人员需要单独进行一些更改。 经过一段时间的工作后，功能流1已创建。 经过更多时间后，将创建功能流2。
然后，某些工作在Main Development流中完成，而某些工作在Feature流中完成。 为简单起见，图中仅显示了少量变更集，但实际上，随着多个开发人员执行其工作，许多变更集可能会交付给每个流。 完成功能流1的工作后，团队决定将其与主开发流集成在＃2点。 本文稍后将描述将工作从一个流集成到另一个流的具体过程。 从交付点开始，将创建功能流2，并继续在三个单独的并行流上进行工作。 当到达点＃3和＃4时，在两个功能流上完成的工作都将传递到Main Development流中，并在＃5处创建基线以进行发布。 从要素流最终交付后，将删除这些流。
添加共享的集成和发布流
如图2所示，在上一节的场景的基础上，现在向场景中添加了一个附加流，以提供单独的Integration和Release流。 图3显示了新方案，随后的文字对此进行了说明。
图3.具有共享的Integration and Release流的功能流
更改集创建，基线创建以及工作从一个流到另一个流的集成的方案遵循“ 功能流 ”部分中描述的模式，并进行了一些小的更改。 集成和发布流将用于在发布之前对应用程序进行正式集成和系统测试。
- 基线显示在“主要开发”流中的＃3中，并在＃4处传递给Integration流。
- 然后，可以在集成和发布流中从基线5发布之前测试集成的应用程序。
- 然后，在功能流上进行进一步的开发工作，直到点＃6和＃7，然后将这些点传送到＃8的主开发流。
- 然后关闭并删除功能流2。
- 在Main Development流程上进行进一步的工作，直到第9点为止，在此处创建新的基准并将其交付给Integration and Release流程。
- 然后，在共享集成和发布流中的＃10处创建一个新基准，以管理正式发布。
拆分集成和发布流
随着时间的流逝，团队经常发现出于以下原因，将Integration和Release流拆分为单独的实体很有用：
- 将发布流从开发中分离出来，使团队可以通过控制允许向其交付角色来提高发布流的安全性。 请参阅本文后面有关安全性的部分（ 控制向流的传递 ）。
- 可以对集成流进行代码修改所需的修改，而不会影响单独发行流的完整性。
- 实时系统支持所需的更改可以与主要开发隔离开，从而可以进行此类更改（通常对配置文件进行更改）而不会影响主要开发。 但是，应该有一条捕获此类更改并将其反馈给Main Development流的途径。 如果发布流不是孤立的，则可能需要与尚未完成或尚未准备生产的部分集成代码一起进行此类更改。 这可能会导致生产复杂化或延迟对实时系统进行的紧急修复。
图4显示了Release流和单独的Emergency Fix流的引入，以捕获实时系统更改。 后续部分将介绍捕获此类紧急更改并将其反馈给开发人员的过程。
图4.单独的集成，发布和紧急修订流
选择了基线5上的应用程序代码以将其发布到生产环境，因此已创建了新的Release流层次结构来管理发布和任何紧急补丁工作，如下所述：
- 在＃6创建了一个新的发布基准，并由此创建了一个紧急修复流（可能会或可能不会实际使用）。
- 在点＃7，执行了紧急更改，该更改在＃8处传递到Release流。 大多数组织对允许在“紧急修复”基础上执行的更改的类型和数量都有严格的规定。 许多确实允许紧急修复的组织也很头疼，无法确保将此类更改流回开发团队。
- 在＃11，将代码从“紧急修复”流传送到“主要开发”流，以确保开发人员进行此更改以将其合并到应用程序的下一个正式版本中。 从“主要开发”流中，可能也有必要将紧急修订内容传递到功能流1或功能流2（或两者），但这未在图中显示。
- 在发布过程进行时，功能流上完成的工作已传递到＃9和＃10的Main Development流中。
- 在Main Development流上进行进一步的工作，直到过渡基线＃12，然后将其传递到Integration流，在Integration Stream在＃13创建Integration流基线以准备下一个版本。
- 图5中显示了用于管理此发行版的Release流和Emergency Fix流的创建。
图5.创建第二个Release流结构
在图5中，发布了发布流，紧急修复流创建和紧急修复工作的又一个周期，涉及多个修复。 图中显示的最后一项活动是将紧急修复程序交付回Main Development流。
为每个主要版本创建一个新的“发布和紧急修订”流，因为可能有必要在第一个“发布”流上继续进行“修订和发布”过程，以在标识为＃7的基础上提供第二个修订版本基准。 当不再需要维护发行版时，可以删除发行版和紧急修订流。
本节中的最终流程关系图显示了开发期间流的进出如何。 图6显示开发过程已经继续进行，要素流1和2已经完成，所有工作都已交付，并且流已删除。 Feature Stream 3已创建，用于进一步的开发活动。 与基线＃8相关的发布也已经完成，并且尽管保留了Release流，但可以安全地删除Emergency Fix流。
图6.进一步的开发活动
流的创建和删除顺序指示团队的发展风格。 如图7所示，该项目从单个开发流开始，随着项目在迭代过程中的进行逐渐变得越来越复杂。 通过去除不再需要的流，可以使结构保持尽可能简单。 该文档后面的屏幕图像显示了Rational Team Concert如何生成流，存储库工作空间及其关系的图形表示。
图7.在整个项目生命周期中的流活动
创建流结构
一个新项目
在Rational Team Concert中创建新项目时，它只有一个包含缺省组件的流。 可以根据需要创建其他组件，但是出于本文档的目的，将使用单个组件。 图8显示了一个只有一个开发人员存储库工作区的新项目的流和用户存储库结构。
图8.初始项目流和存储库结构
可以使用流程图可视化流和任何连接的工作空间，如图8右侧所示。用户可以看到流和用户存储库工作空间的层次结构，还可以显示连接到其他流的流。 必须记住，Rational Team Concert本质上是扁平的，并且只要基于角色的权限允许，任何工作空间都可以传递到任何流。 （权限在本文的最后一部分中介绍。）
为了传达所需的变更流，项目团队应使用文档，例如图2至6中的图。这将帮助各个开发人员了解其变更应流向何处以及负责将工作交付给特定流。 此类文档应经常更新，以使每个团队成员都随着流的结构的发展对自己的职责有很好的了解。
更多用户加入该项目
加入项目的新用户可以通过创建新的存储库工作区，在源代码控制下访问文件。 只需选择图8中所示的My Repository Workspaces项，然后选择New ，然后Repository Workspace将执行此操作。 然后将显示一个选择对话框窗口，如图9所示，因此您可以选择将更改交付到的流（“流”）。 一个项目的流总数通常很小，因此，如果为流指定合理的描述性名称，则很容易选择要使用的正确流。
图9.选择变更将流向的流
创建第二个流之后的流程图如图10所示。请注意，可以通过右键单击流或屏幕左侧的存储库工作区时显示的菜单项来创建流程图。如图8所示。
图10.连接到同一流的多个用户
创建新的流
有几种创建新流的方法。 最简单的方法之一是使用流程图以图形方式显示流和存储库工作空间之间的关系。
右键单击流会显示一个菜单，其中包含各种功能和选项：
- 创建一个新的存储库工作区
- 创建一个新的流
- 用存储库数据库中保存的信息刷新图
- 将流的状态与以下任一状态的当前状态进行比较：
- 另一个流
- 特定的工作空间
- 流的特定快照
选择创建新流的选项时，要求您提供流的名称以及项目中拥有该流的团队区域。 如果项目内不存在团队区域，则会显示项目名称。
在图2的场景中，要创建的第一个流将是“功能流1”。 流创建后立即具有与创建流相同的内容。 此外，新流与任何其他流没有流关系，并且没有关联的工作空间。
关于流到流的注释
流之间的流关系不一定表示文件内容从一个流直接流向另一流。 随着流结构的演变，如以下几页所示，在流之间创建流关系以显示意图收集一个流中的更改，然后将部分或全部更改移至下一个流可能是有利的。 稍后部分将详细介绍使内容从一个流流向另一流的两种方式。
要创建流之间的流关系，必须打开源流的详细信息，如图11所示。
图11.源流细节
流的信息对话框允许执行以下功能：
- 创建新组件
- 添加或更新其他项目的参考组件（在特定基准下）
- 流量目标的添加和删除
将新的流程目标添加到功能流1，以指示对主要开发流进行更改的流程。 在图12中显示了流的配置。
图12.流配置显示指示性的变化流
更新后的流程图如图13所示，还显示了三个正在开发Main Development流的开发人员。
图13.显示流和存储库工作区的流程图
如图14所示，向场景中添加了功能流2，从而完成了图2中的图所示的场景。
图14.两个功能流和主要开发流
完成新流创建
为了完成图4所示的流结构，包括实际的集成，发布和生产热修复流结构，将创建新的流，并使用前面描述的机制建立流目标关系。 结果如图15所示。
图15.开发，集成和发布流
图15的左侧显示了该团队的开发活动，其中两个开发人员（Mark和Simon）在Main Development流中工作，而Adrian在Feature Stream 1中进行工作（以前已配置为在Main Development流中工作） ，Adrian现在正在单独开发流中的特定功能）。 马克和西蒙通过将变更集交付到“主要开发”流以及随后接受来自“主要开发”流的变更集来整合他们的工作。 该图已简化为每个流上的用户数量。 预计Adrian和其他开发人员将在Feature Stream 1上进行协作，而其他开发人员将在Feature Stream 2上进行协作。
“主要开发”流右侧是支持发布和紧急修复过程的流结构。 集成流用于开发变更的逐步（和受控）集成。 在Integration流上创建合适的基准之后，Integration流的当前状态（更改集和基准）将传递到Release流1.0。 创建了特定于版本的Release流，如图4所示，也如图15的流程图所示。这是为了允许维护多个Release流，以支持多个生产同时使用的情况。时间。 此类发行版可能需要应用紧急修复程序。 在图16的示例中，要创建的第一个版本在基线＃8处应用了紧急更改集。 拥有该应用程序版本的客户可能需要在基准＃8之后进行其他紧急错误修复，但他们可能无法采用第二个发布流中显示的应用程序的最新主版本。 因此，保持将修补程序应用于在基线6创建的发行版的能力很重要。
图16.发布和紧急修复流的详细信息
紧急修订流在图15上显示为“ Release Stream 1.0 – E-Fix”，用于紧急更改，必须尽快将其应用于生产用途。 预计此类更改不会涉及源代码和重新编译，但是在许多情况下，它们适用于需要立即更新的配置文件和设置。 它们仍被捕获在隔离的流上，以确保Release流不用于任何开发活动。 开发流中也可能需要紧急修复更改，以便这些更改自然地流到下一个版本。 图4显示了标识为＃7的变更集正在交付给＃11的Release流和Main Development流。
将用户连接到流
在并行开发方案中，作为开发活动的配置管理方面的一部分，用户需要完成两项主要任务：
- 创建工作空间以提供与其他用户的一定程度的隔离，并连接到并行开发工作的特定流。
- 将他们的更改传递到适当的流。 有时在开发过程中，随着活动在开发过程中发生变化，开发人员有必要切换其工作区的流程目标。
在上一节中介绍了新工作区的创建。 The connection of a workspace to different streams for the delivery of work is described in the following section.
Changing the target stream for delivery
In the scenario shown in Figure 2 a developer has made a change on Feature Stream 1. This change set may contain multiple files and, in accordance with the process of the Rational Team Concert project policies, it will either have a description associated with the change set or a work-item associated with the change set. The changes to file content were performed on a local hard disk of the developer in question and the changes were then checked-in to the server side repository workspace and collected into the change set, as shown in Figure 3. The changes are then delivered to a specific stream. In the scenario shown in Figure 15, the users Mark and Simon deliver their changes to the Main Development stream, but Adrian delivers his changes to Feature Stream 1. The target stream for a delivery operation is a characteristic of the developers' repository workspace as shown in Figure 17 for the user Mark.
Figure 17. Repository workspace properties
The repository workspace information section displays a number of items of useful information. Relevant to the current topic it includes the flow target for the repository that indicates to which stream deliveries of change sets will be sent. In order to change the flow target select Add (within the flow target section of the screen), and then select the required stream. If the user named Mark wants to deliver change sets to the Feature Stream 2 rather than the Main Development stream, the flow targets section would show as displayed in Figure 18.
Figure 18. Alternative flow target added (but not selected)
At the point of adding the new flow target, there are actually no changes to how change sets will be delivered. To change the actual delivery target, the new target stream must be set as the current target by using the buttons on the right side to result in the workspace state, as shown in Figure 19.
Figure 19. Alternative flow target added (and selected as current)
The position shown in Figure 19 indicates that the default flow target for the specific repository workspace is the Main Development stream but at the present time the current delivery target is selected to be the Feature Stream 2.
This position is reflected in the flow diagram shown in Figure 20. The current flow target is shown with a solid line, and the default flow target is shown with a dotted line.
Figure 20. Flow diagram after setting a new current flow target
The Pending Changes view also shows useful information regarding the flow targets. Any non-default targets are shown in italics on the top line of the Pending Changes information, as shown in Figure 21.
Figure 21. Pending changes view: non-default flow target selected
As a new delivery starts the user is warned that they are delivering to a non-default target with the warning shown in Figure 22, so the user may wish to check that the delivery is going to the right place.
Figure 22. None default flow delivery warning message
The above warning can be removed if the user has completely switched to the stream into which they wish to deliver change sets by switching both the current and default flow targets to the new stream. In this case, the target stream will no longer be displayed in italics as shown in Figure 21.
Changing the flow target from the Pending Changes view
It is also possible to change the flow target of a repository workspace using the Pending Changes view. By right clicking on the name of the repository workspace and then selecting Change Flow Target it is possible to select a new flow target stream.
The Integrator role
There are two ways that work can progress from one stream to another. The first way is to use the repository workspace of a specific integration user, and the second is to deliver from one stream directly to another. The tasks are broadly described as an integrator role. Teams might want to create a specific user role, with appropriate permissions, for the person or small team assigned to this task.
Integration through a repository workspace
The arrows that connect the streams in the flow diagrams in Figures 13, 14, 15, and 20 might be present merely to indicate the intention that work will flow from one stream to another. The actions described in the following section are performed when the integration activity is performed through a repository workspace. As indicated by Figure 4, the changes will flow from stream to stream in the following order (for example):
Feature Stream 1 > Main Development stream > Integration stream > Release stream
The following operations are required to flow change sets from stream to stream:
- Set the current flow target of a repository workspace to the source stream.
- Accept any incoming changes from the source stream to the repository workspace.
- Change the flow target of the repository workspace to the target stream.
- Deliver the outgoing changes.
提示：
It is very useful to perform these steps in a clean integration workspace. Otherwise, the delivery operation at Step 4 could include changes made locally by the developer who is performing the integration operation, rather than just the set of changes that have been collected on the source stream. Also, ensure that there are no outgoing changes listed in the Pending Changes view of the repository workspace before performing the Accept operation in Step 2.
The example that follows shows the steps to flow changes from Feature Stream 1 to the Main Development stream via the workspace owned by the user named Mark.
Collect changes from Feature Stream 1
Set the current flow target of the repository workspace (Mark's workspace) to Feature Stream 1, as shown in Figure 23. The Pending Changes view for the repository workspace then shows incoming changes for the work done on Feature Stream 1 by the user Adrian, as shown in Figure 24. The changes need to be accepted into the repository workspace by the Integrator (Mark).
Figure 23. Repository workspace connected to Feature Stream 1
Figure 24. Accepting changes from Feature Stream 1
Deliver changes to Main Development stream
Set the current flow target of the repository workspace to the Main Development stream, as shown in Figure 25. The Pending Changes view for the repository workspace then shows outgoing changes for the work that is now in the repository workspace, as shown in Figure 26. The changes need to be delivered from the repository workspace by the Integrator, Mark.
Figure 25. Repository workspace connected to the Main Development stream
Figure 26. Deliver changes to Main Development stream
You can use this process outlined to collect changes from any stream and then flow those changes to any other stream. However, a degree of control is required to manage who is allowed to deliver changes to specific streams (such as the Release stream). The following section describes how to control access to streams.
Integration with stream-to-stream delivery
It is possible to deliver changes directly from one stream to another by following the stream flow hierarchy. To do this, the stream flow targets must be set correctly, as described previously in this article. The person who performs the stream-to-stream delivery does not need to change the target of the repository workspace. In fact, that user does not even need to have a repository workspace.
Figure 27 shows the starting point for the delivery of changes from Feature Stream 1 to the Main Development Stream.
Figure 27. Stream-to-stream delivery starting point
To initiate the stream delivery process, it is necessary to identify the changes pending in a specific stream that are relevant to the default target stream. In the example in Figure 27, this means identifying the pending changes in Feature Stream 1 that are not currently present in the Main Development stream.
To do this, right-click Feature Stream in the Source Control area of the project structure within the Team Artifacts view, as shown in Figure 28, and then click Show and then Pending Changes on the drop-down menus.
Figure 28. Selection of pending changes for a source stream
The Pending Changes view (see Figure 29) shows the changes that exist in the source stream but not in the target.
Figure 29. Changes pending for a stream-to-stream delivery
You can then finish the delivery in the normal manner.
Stream-to-stream delivery conflicts
A merge conflict might result during a stream-to-stream delivery. For example, in the scenario that Figure 27 shows, developers who are connected to the feature stream and the main development stream could make a conflicting code or structure change. When this happens, the Pending Changes view for the stream-to-stream delivery will be as shown as in the example in Figure 30.
Figure 30. Stream-to-stream delivery conflict
When this situation arises, the solution is to resort to using a repository workspace to overcome the merge issue, as shown in Figure 31, where the repository workspace for the main development stream has been temporarily redirected to the feature stream.
Figure 31. Using a repository workspace to resolve a merge conflict
The incoming change from the feature stream can be accepted and the merge resolved, and then the result can be delivered back to the feature stream. This will allow the feature stream to main development stream delivery to finish.
For the reasons shown below, stream-to-stream delivery is particularly useful in the progression of work from one stream to another along a series of project phases. For example, Figure 20 shows the progression from the main development stream to the integration stream to the release 1.0 stream and, finally, to the release stream 1.0 E-Fix. Such progressions of stream-to-stream deliveries establish a structure that is then used for further project maintenance. In the areas of work covering the main development stream and the interaction with changes that involve the feature streams, the use of an integration workspace is better for simplicity.
Controlling deliveries to streams
You can use that Process Configuration area of the project to specify which project roles are allowed to deliver changes to specific streams for a specific component. You can find the appropriate area of the configuration by following these instructions within the Eclipse interface of Rational Team Concert:
- Select Project Area information.
- Select the Process Configuration tab.
- Select Team Configuration > Operational Behavior .
- Select Source control (Deliver Server).
- Select the Everyone (default) column heading.
- Check the box for "Preconditions and follow up actions are configured for this operation."
- Select Add , and choose the precondition called Restrict Change set delivery to components in a particular stream .
注意：
You can do this in the web interface, too.
Figure 32 shows the result.
小费：
You can do this using the web interface, rather than the Eclipse one, if you prefer.
Figure 32. Process configuration for delivery control
On a stream-by-stream basis, it is then possible to control which roles have the permission to deliver change sets, as shown in Figure 33 (which is actually the bottom section of Figure 32 made a little larger for readability).
Figure 33. Role-based permission control for delivery of changes
By selecting a specific stream, such as Release Stream 1.0, it is then possible to click Edit Permissions button to control which roles are allowed to deliver to the stream. Figure 33 shows that a new role called Release Stream Integrators has been created, and only members of that stream are able to deliver to the Release Stream.
Summary
Rational Team Concert offers a highly collaborative environment for the reality of today's software development projects. Most teams need to support multiple threads of development and to share changes with others working on the project. The stream structure and relationships with the user workspaces make such processes not only possible but a highly effective way to segment and isolate work efforts to maximize the efficiency of the software development team.