使用 Jazz 源代码控制进行多流程控制

最新推荐文章于 2020-06-29 00:23:58 发布

cslsa42868

最新推荐文章于 2020-06-29 00:23:58 发布

阅读量194

点赞数

1.独立开发

本例将会从一个人的团队开始。Markus 开发了一种测试框架叫做 JUnit。他在他的 Eclipse 工作区中有一系列的项目；第一个是核心库和使用，而另一个就是一系列的范例。为了使用 Jazz SCM 中的版本支持功能，以支持备份工作，并追踪储存库中的变更，您所需要的一切就是一个储存库工作区。如图 1 所示，您可以使用 Team > Share Projects... ，来与 Jazz Source Control 共享项目，并从向导中直接创建一个带构件的储存库工作区。

图 1：使用没有流的储存库工作区

一旦您已经有了创建并载入的储存库工作区，那么 Pending Changes 视图将会显示两个添加到变更集中的项目，注意在图 2 中，因为 Markus 的储存库工作区还没有流变更，所以 Deliver 操作不能使用， Accept 操作甚至没有显示出来。在没有流变更的工作区中，流目标将会列在工作区节点的右边：本例中的 JUnit，这正是变更流向和来源的暗示。

图 2: 没有变更的储存库工作区中的项目附件

当 Markus 变更他的本地 Eclipse 工作区中的文件时，他创建了 Pending Changes 视图中未解决的变更。当他决定怎么处理服务器上的这些版本时，他可以使用 Check-in 操作来检查同一变更集中的未处理变更。当他处理变更的逻辑集时，他可以通过在 Pending Changes 视图下点击它，并运行 Complete 操作，来完成变更集，从这一点开始，所有新的变更都会添加到一个新的变更集中。这种储存库工作区中变更集的稳定积累，与您每次检入时其他 SCM 系统发生的状况相类似，但是不同的是，在 Jazz 中您可以更好的掌控包含在变更集中的内容。如果您喜欢模仿传统的 SCM 系统，您可以在每一次检入之后，设置一个对自动完成变更集的引用。现在是您该决定做什么的时候。因为您可以在您的储存库工作区中积累完成的变更集，您可以使用 History 视图和 Change Explorer 以浏览您所做的变更。

1.1 基线

在开发进行中时，Markus 最终对他的代码很感兴趣，并想要记住基线中所有变更的当前状态。基线可以从他的储存库工作区中创建。从 Pending Changes 视图中，选择构件并运行 New > Baseline....。基线可以自动编号；就象这样，指定一个名字和描述都是可选择的。在储存库工作区或者流中一直有当前的基线，指示了该工作区或者流中构件的最新基线。

基线可以通过储存库工作区和流来追踪。这意味着您可以通过浏览一个构件，并运行 Show > Baselines ，来浏览基线的历史。在图 3 中， History 视图显示出了初始的基线和叫做 GOOD 的新基线。双击 History 视图中的基线，可以与前面的基线相比较，并显示出 Change Explorer 视图中的结果。注意 Change Explorer 标签显示了比较的两个基线。

图 3: 浏览基线历史

如果一个工作区和它的附件拥有不同的基线，那么基线 Pending Changes 视图会显示为 Incoming 或者 Outgoing。接受或者交付一个基线就是接受所有对该基线独特的变更集，以及工作区构建基线的基础。这对快速识别工作区或者流中构件状态的不同累计来说，是十分有用的。

1.2 返回

尽管我们都喜欢往前走，但是返回来重新构建生成一个构建，或者变回成一个两良好的状态通常是十分有用的。当您决定返回时，您必须首先考虑在您储存库工作区中，有什么还没有交付给流的。如果您只有暂时不需要的变更集，那么您可以使用 Pending Changes 视图或者 History 视图，来展暂时不去处理它们。如果您做了大量的变更，那么您只需创建一个新的基线，例如，叫做，BROKEN，并从 Pending Changes 视图中选择构件（例如 JUnit）并运行 Replace With > Baseline...，指定 GOOD 基线。Replace 操作将会更新储存库工作区中的构件，并载入您的本地工作区，以匹配储存库工作区内构件的内容，而您创建的 BROKEN 基线，可以记起您执行 Replace 之前的 JUnit 的状态。

浏览您创建基线时的文件和文件夹也是可能的。从 History 视图中，选择一个基线并运行 Show Repository Files。这将会打开一个储存库文件浏览器，如图 4 所示，这样您就可以在基线中浏览文件的状态了。如果您想要获取一个文件的特定状态，您可以选中它并运行 Load ，该操作将会把文件的内容转移到本地 Eclipse 工作区中。

图 4: 浏览基线中的文件

2.括展

我们已经看到了独立工作是可能的，但是 Jazz 不仅仅是一个团队，所以让我们去发展一个 JUnit 团队。Markus 把Jason 添加到他的团队中，以帮助改善范例。他同时决定了范例不去处理主要的程序，并希望有一个团队致力于写范例，这样就可以把团队分成几个构件，就能够独立的进行开发了。结果，Markus 发展的流结构如图 5 所示。

图 5: 添加一个流

要做的第一件事情便是创建新的结构，并将范例项目移动到里面。创建一个构件是在储存库工作区编辑器中完成的。您可以在储存库工作区从 Pending Changes 视图中通过运行 OPEN ，来打开储存库工作区。一旦打开了编辑器，您可以在编辑器的构件部分中点击 New...，来创建构件：给新构件起名为 Examples。

为了将 Junit Examples 项目移动到 Examples 构件中，您应该来到 Java Package Explorer 或者 Navigator ，并执行以下的步骤：

选择 JUnit Examples 项目并运行 Team > Move In Repository... 。
在出现的对话框中，选择 Examples 构件，再选择 OK 以继续后续操作。
在 Pending Changes 视图中您将会看到移动源和目标的变更集。储存库中的项目实际上保持一致，历史记录也会保存下来，它们只是简单的移动到另一个构件中去。

接下来，我们将会创建流结构。从储存库工作区中创建新的流是十分简单的，在 Team Artifact 导航器中选择工作区，并运行 New > Stream。这将会创建一个新流，复制储存库工作区的内容。下一步， Jason 可以像以前一样创建他自己的储存库工作区。从现在开始， Jason 和 Markus 可以接受和交付共享它们的变更。

2.1 第一个客户

是时候该与外部的用户共享它们的代码了，Markus 或者 Jason 可以使用一个快照，以记住呈递给用户的状态。为了创建一个快照，在 Pending Changes 视图中选择储存库工作区节点，并运行New > Snapshot... ，给它起名字为 JUnit 0.1。在创建一个快照时，它可能会为构件创建一些基线，构件的最新变更还没有被基线所获得。快照和流、工作区一起被记住；默认条件下，在创建快照时，它会和快照的源一起记住的。为了查看快照，选择一个流或者工作区，并运行 Show > Snapshots。快照可以同时与不止一个流或者工作区一起记住；一般的模式是，将“受关注的”快照与相关的流联系以来。这可以使在以后找到它们变得更加容易。

当客户返回并需要一些修复的 Bug 时，提供修复的过程是一个比较容易的过程。如图 6 所示，可以使用另一个流来追踪修复的 Bug ，而且 Jason 可以同时进行两项工作。这里的关键之处在于， Pending Changes 视图允许您在任意的流或者工作区之间切换，您可以从中进行流变更。使用 Change Flow Target 操作来配置流目标。这可以让平行开发变得非常简单，因为在同一工作区中所有的流都可以运行。

图 6: Bug 修复流

创建 Bug 修复的第一步，是从快照中创建新的流。打开快照编辑器，并在 Links 部分中运行 Create a new stream 链接。这将会创建一个带有确定内容的流。

2.2 自动化的构建

既然有一个客户，那么让构建配置自动化是一个不错的注意，它可以自动化使用的二进制，并自动运行测试单元。当在创建自动化的构建时，如同在开始设置 Jazz Build，所述的那样，这只是一个简单的过程，只不过是从运行的构建中创建工作区，如图 7 所示。配置构建储存库工作区的流，以接受需要构建的流。

图 7: 添加构建工作区

这里有一个来自为 Jazz 配置的典型 Ant 构建脚本的范例片段。在构建运行时，它首先会接受所有的变更集，然后创建一个储存库工作区的快照：

    <!-- Accept any changes into the workspace. --&gt
    

    <!-- Load workspace files to the build machine filesystem --&gt

在构建中创建的快照，会在追踪构建结果，并可以从构建结果编辑器中获得。这意味着为了生成一个构建，您可以简单的打开构建结果，并点击快照链接。然后您可以从快照编辑器中创建一个储存库工作区，或者您也可以运行储存库工作区节点上的 Replace With > Snapshot...，来使用快照，来替换 Pending Changes 视图中的任意储存库工作区。

2.3 添加集成的层次

随着一个团队的发展，越来越多的人参与进来，越来越多的事情要做，这样导致了一些构件过于频繁的变动，并让日常的集成工作花费太高。例如， Jason 可能在与 Markus 核对工作时，非常困难，当 Markus 的团队也得到一定的发展时，他需要经常向您的流交付他的流，Bill 可能会破坏 Jason 的代码。解决这种增长问题的最好的方式，是添加一个如图 8 所示的特别流层级结构，如图 8 所示，为团队的一些成员提供一种方法，相互之间更加频繁的交流，并且可以与更大型团队的剩余部分共享。

Markus 创建了 JUnit Integration 流，而且其他流中工作的子团队，可以以预定的时间间隔向它交付变更。另外， JUnit 流不再拥有 Examples 构件：现在轮到 Examples 团队采用出现的变更，并将这些应用到 JUnit Integration 中。

团队可以自由选择他们需要多少的子特性流，如果有够多的流的话，同时它们也可以自由选择多久向集成的流，交付他们的变更。作为这个反集成过程的一部分，可以采用多种质量把关方法；例如，除非在经过一系列的测试之后，才可以进行交付，否则拒绝，包括性能测试，跳过。

图8: 分割团队

来自 JUnit Integration 变更交付的应用，直接来自于 Pending Changes 视图。 Jason 可以从 JUnit Examples 流到 JUnit Integration 流中变更他的流目标，检查变更，接受它们并执行规则的采用不再，例如确保范例仍然汇编，并且运行测试，关于模型比较重要的一点，是 Jason 可以在不影响其余团队成员的前提下，采用新的变更。如果在采用期间发现了一些问题，那么 Jason 可以简单的与其余团队成员协商一下，直到问题得到解决，同时，团队的其余成员仍然不受这些问题的困扰。一旦采用完成，Jason 只需简单的在 Pending Changes 视图中，将他的流目标变更为 JUnit Examples 流，并交付 JUnit Examples 中的应用，以及来自 JUnit 中的新变更。

2.4 回退变更

Markus 在他的框架中没有涉及到一个重要的问题，并向包含修复工具的JUnit 流发布了一个变更集。Bill 说服 Markus ，这个问题应该在 JUnit 0.1 流中解决，这样如果如果有 JUnit 0.1 Integration 的维护版本的话，那么这个问题就可以在这里被解决掉。Markus 只需简单的对 JUnit 0.1 运行 Change Flow Target...，然后运行 Replace With > Latest from JUnit 0.1。现在他与维护流又保持了同步化。为了对他当前的环境接受修复，他有一系列的选择：

如果变更集附属到工作项中，那么 Markus 可以从那里接受它。
如果 Markus 在前面已经冻结了他的变更集，那么 Markus 可以将其恢复到他的工作区中。
Markus 可以与 JUnit 流合作，并只接受他希望回退的变更集。

Markus 决定与JUnit 合作，并只接受那里的单个变更集，当 Markus 与 JUnit 流合作时，他可以看到很多种输入以及输出的基线，如图 9 所示。Markus 意识到他不想接受任何基线，因为他不想完全受限于 JUnit，他只想要单个变更集。他打开输入文件夹找到变更集，选中它，并运行 Accept。

图 9 : 接受单个变更集

如果 Markus 的变更集不是建立在，JUnit 流之外的其他变更集上时，他是十分幸运的，会看到工作区顺利的接受了变更集。如果 JUnit 和 JUnit 0.1 发生了严重的分离，那么很可能 Markus 的变更不会被那么顺利的接受。现在，Marcus 是就不这么幸运了，他的变更集不能被这么直接的接受；相反，他会被提供一个选择，以将这些变更作为工作区的补丁，如图 10 所示。

图 10 : 作为补丁使用对话框

Markus 决定了将变更集当做一个补丁使用。Pending Changes 视图中出现的一个新节点，叫做 Pending Patches, 如图 11 所示。Markus 可以使用合并编辑器，以一行行的合并特定的变更，这些变更是他需要处理以回退的。当他对他的变更很满意的时候，他可以将他的变更检入到一个新的变更集中，并运行补丁节点上的 Remove From View ，以移除来自 Pending Changes 视图的补丁信息。然后 Markus 只需简单的将他的流目标变回到 JUnit 0.1 流，并在确认它满足交付标准后交付变更。

图 11 : 未处理的补丁