控制跨多个差异性的变更
Now, let's imagine that we have a microlevel change (e.g., a bug fix or small enhancement) to make. If we are developing variants, there are three possibilities:
Case 1: The change is required by just one variant of our product; for example, the change might be specific to software running on the MS-Windows platform.
Case 2: The change is required by all variants; for example, the change might relate to how a calculation is performed, which should be platform independent.
Case 3: The change is required by selected variants; for example, a change might be required only for the variants created for Japanese and Chinese customers.
Case 1 is relatively easy to deal with. So is Case 2, provided that the project team has a good architect; the calculation could be compartmentalized into a single component that is shared among all variants. Case 3 requires selectively propagating the change to multiple variants, which is where UCM can really help out.
现在，让我们假设我们有一个微粒级的变更（比如，一个bug fix或一个小的优化需求）。如果我们正在开发是差异性版本，将有三种可能：
可能1：这个变更只需要在我们产品中的一个差异性版本中实现。比如，这个变更可能只针对运行在MS-Windows平台的版本。
可能2：这个变更可能需要反映在所有差异性版本中；比如：这个变更可能是关于如何执行一个计算的，这样的功能通常与平台无关。
可能3：这个变更可能只需要反映在某几个差异性版本中；比如，这个变更可能只需要
实现在日本和中国客户的版本中。
可能1相对比较容易处理。可能2也是，只要这个项目团队有一个好的架构，这个计算可以划分成一个独立的模块，该模块可以在所有差异性版本中共享。可能3需要有选择性地在多个版本中传递，这就是UCM真正能帮得上忙的地方。
Let's review in detail how UCM assists teams in each of these situations.
Under the UCM model, the team would walk through the following steps:
Step 1: When starting on a project, each team member "joins" the project. This creates a view for the person to work in. The configuration of that view is based on a new stream that tracks the changes made by the team member.
Step 2: An activity is created (perhaps by the team leader) and assigned to the team member.
Step 3: This team member accepts the activity within the context of the stream and commences work. As the stream has preconfigured the working area (view), development can start immediately.
Step 4: Eventually, the change is completed. At this point, the team member could either take on other related work or baseline the stream to capture the state of the artifacts at that point in time.
Step 4a: In Case 1 (change required by just one variant), there might be integration required with others working on the project, but the work is
otherwise finished.
Step 4b: In Case 2 or Case 3 (change required by some or all variants), we would also need to go through integration. This time, we could make use of the automation provided by the tool (Rational ClearCase) to deliver changes to multiple destinations (product variants).
让我们仔细分析UCM在以上三种可能性中如何帮助团队。在UCM模型中，团队会经过以下几个步骤：
步骤1：当开始一个项目时，每个团队成员“加入”一个项目。这将为这个成员建立一个工作视图。这个视图的配置是建立在一个新的工作流的基础上，成员的所有变更由工作流来跟踪和记录。
步骤2：创建活动（可能是团队主管）并指派给团队成员。
步骤3：团队成员接受这个活动并着手开始工作。由于工作流有一个预先配置好的工作空间（视图），开发活动可以立即开始进行。
步骤4：最终，变更完成。在这个时候，团队成员应该可以进行其他相关工作或建立基线来捕捉所有工件的当前状态。
步骤4a:在可能1（变化只针对一个差异性），这时有可能需要集成项目的其他工作，否则工作就到此完成。
步骤4b:在可能2或可能3（变更针对一个或多个差异性），我们可能同样需要集成。这时，我们可以充分利用工具（Rational ClearCase）的自动化功能来提交变更到多个不同的目标工作流（差异性版本工作流）。
Example: Developing a GPS Tracking System
举例：开发一个GPS跟踪系统
Step 4b clearly needs additional explanation; let's do this by walking through another example: the development of a GPS tracking system originally created for in-car use. Let's suppose that, although the original system is successful, it has not been widely adopted in the prestige car market. To break into this market, a number of new features are required (i.e., a variant), which in turn require changes to existing software components. In addition, we want to create variants for trucks and handheld devices.
步骤4b明显需要更多诠释，让我们通过演练另外一个例子来解析这一点：开发一个GPS跟踪系统。这个系统最初是为车载使用开发的。让我们假设，尽管最初的系统开发是成功的，但它还是没有被广泛应用到高档车市场。为了突破这个市场，需要增加很多新的特性（也就是一个差异性），这些特性反过来需要修改现有的软件组件。而且，我们还想开发适用于卡车和手持设备的差异性版本。
The Problem
问题
For the hand-held device, the graphics software for the GPS tracking system needs to be modified to deal with the screens used in these devices. The team working on the prestige car project also needs these changes, as they want to adopt similar hardware to reduce sun glare.
对手持设备，GPS跟踪系统的图形软件需要修改，以符合在这些设备上的显示器要求。开发高档车应用系统的团队同样需要合并这些变更，因为他们希望使用类似的硬件来减少阳光直射。
The UCM Solution
UCM 解决方案
The UCM solution to this problem is sketched out in Figure 1. To solve this
problem, the team used multiple streams:
A stream for each variant.
A stream to group activities common to multiple variants.
If the team had made modifications required to support the screens directly within the hand-held variant stream (by checking out files from a workspace [view] associated with that stream), it would have been difficult to share these modification without also sharing the activities specific to the hand-held variant. So instead, the team used a "Graphics Changes" stream to capture all the development changes and then "deliver"4 (to use more UCM terminology) these changes to each variant that needed them -- in this case, the hand-held and prestige car streams
UCM针对此问题的解决方案在图1中勾画出来。为解决这个问题，团队使用多个工作流：
为每个差异性建一个工作流
一个组织所有差异性版本共同活动的工作流。
如果团队已经直接在手持设备差异性工作流里进行修改来实现这个显示器需求，（从和工作流关联的工作空间[视图]检出文件），这时如果不同时共享那些专属于手持设备差异性工作流的活动，则将难以共享这些修改。所以，团队用另外一个“图形变化”工作流来组织所有开发修改，然后交付（UCM术语）这些修改到每个需要它们的差异性工作流---在这个例子中，即手持设备工作流和高档车工作流。
图1：使用工作流来管理差异性
Let's get down to the "nuts and bolts" of setting up this mechanism. First, the developer creates a new view to provide a workspace to modify files and directories, and to build and test the changes. He can either select the Graphics Changes stream or request that another stream be created. For the moment, let's assume he uses the Graphics Changes stream.
让我们深入了解一下建立这种管理机制的具体细节。首先，开发人员创建一个新的视图，提供修改目录和文件的工作空间，同时可以构建和测试这些修改。他既可以选择图形变化工作流或要求创建另一个新的工作流。现在，让我们假定他使用图形变化工作流。
To modify a file (e.g., graphicsdriver.cpp), the developer must check it out
from the workspace. Of course, he needs to check out the correct version If he is using UCM, he knows it is the correct version because the developer is working in a ClearCase view (i.e., a workspace), and ClearCase view is associated with a stream, which automatically configures the view with the latest set of file and directory versions. In response to a check out request, the stream selects a file that reflects the baseline (tested and reviewed component versions) the stream is founded upon, plus changes to this baseline.
修改一个文件（如：grahicsdriver.cpp），开发人员必须先把它从工作空间中检出。当然，他需要检出正确的版本。如果使用UCM，开发人员知道这是正确的版本因为他是工作在一个ClearCase视图中（即一个工作空间），而视图与工作流关联，工作流自动将视图配置成文件和目录的最新版本。为响应一个检出请求，工作流选择反映其创建基线（经过测试和审核的组件版本）的文件版本，加上此基线上的变更。
When the developer checks out a file, UCM forces him to specify the context for his modifications -- that is, the activity to which he has been assigned. Checking in a file creates a new version for that file, and the activity's change set is updated to record this new version. ClearCase also automatically updates the configuration of versions in the developer's view so that he will select this new version. In our example, the developer modifies graphicsdriver.cpp to support new graphics hardware, so the activity might be called "Activity 263: Support New Graphics Hardware model 654 from VeryGoodGraphicsHardware Corporation."
Once the developer makes all the changes, he (or the integrator, depending on the organization's size and preferences) can perform delivery as follows:
当开发人员检出一个文件，UCM强制他指定修改的原由---也就是，指派给他的某个活动。检入文件时为该文件创建了一个新的版本，活动的变更集也同时更新来记录这个新的版本。ClearCase也自动更新开发人员视图的版本配置以便他可以选择这个新的版本。在我们的例子中，开发人员修改了graphicsdriver.cpp来支持新的图形硬件，所以活动可以命名为“活动263:支持新的图形硬件模型654自VeryGoodGraphicsHardware公司”。一旦开发人员完成了所有修改，他（或集成人员，取决于公司规模和选择）可以按以下步骤执行交付：
1. The developer selects the view with the changes, clicks a "Deliver" button, and selects the destination -- in this case the hand-held variant stream.
2. ClearCase finds the activities that have not been previously delivered5 . Then, using the change set for each of these activities, it determines the changes, at a file and directory level, that should be incorporated into the destination stream.
3. The developer/integrator may review the activities (e.g., Activity 263) and changes (e.g., versions 1, 2, and 3 created on the Graphics Changes stream of graphicsdriver.cpp) to be delivered, and then either proceed or perform further quality assurance procedures, such as peer reviews of these versions.
4. When the developer/integrator decides to proceed, the destination (hand-held) stream is updated to include all activities created or modified (such as Activity 263) within the Graphics Changes stream since the last delivery. At a file level, this means:
EITHER: ClearCase will update the hand-held variant stream so that a different version of graphicsdriver.cpp will be selected in views that are configured by this stream, OR: If graphicsdriver.cpp has already been modified in the hand-held variant stream, ClearCase will merge the modifications made by the Graphics hanges stream with the modifications already present. Note that this merging procedure is quite robust for many file types (text, HTML, XML, etc.) but is problematic for binary files. In either case, the user may choose to be informed of the changes
made and review the automated modifications before committing to them.
1．开发人员选择做了修改的视图，点击“Deliver”按钮，然后选择目标工作流---这里是手持设备工作流
2．ClearCase查找那些它以前没有交付过的活动。然后，通过这些活动的变更集判别文件和目录级的变更，这些变更将被纳入目标工作流。
3．开发人员/集成人员可以审核这些即将交付的活动（如：活动263）和变更（如：图形变化工作流上graphicdriver文件生成的版本1，2，3），然后继续执行或者进行一些更进一步的质量保证措施，比如同行评审这些版本。
4．当开发人员/集成人员决定交付，目标工作流（手持设备）工作流被更新并纳入在图形变化工作流中自上次交付以后所有新建或修改的活动（如活动263）。在文件级，这意味着：
或者：ClearCase会更新手持设备工作流以便graphicsdrive.cpp的新版本更新到这个工作流的视图中。
或者：如果graphicsdriver.cpp已经在手持设备工作流里被修改，ClearCase会归并图形变化工作流里的修改和已有的修改。注意这个归并过程支持许多文件类型（文本，HTML，XML等等），但对二进制文件会出现问题。在这两种情形中，用户都可能想知道做了哪些修改并在确认归并前检查自动归并的结果。
Tracking the Work of Multiple Developers
追踪多个开发人员的工作
If the graphics changes required are quite significant, several developers might be assigned to the task. If all of these developers work on the same Graphics Changes stream, even with separate workspaces, issues can arise that impact productivity.
如果图形变化需求较大，可能会指派多个开发人员开完成这个任务。如果所有的这些开发人员工作在同一个图形工作流，即使是隔离的工作空间，也会影响开发效率。
Let's suppose that Bob and Wendy are both assigned to the graphics work and have split the work between them: Bob does Activity 263, and Wendy does Activity 264: Improve Graphics Rendering Performance (Figure 2). Wendy determines that Activity 264 requires modifications to the graphicsrendering.cpp file, so she checks it out and makes modifications. Wendy, being the conscientious developer she is, decides to test these changes. To perform the test, she tries to build the software. Sadly for Wendy, Bob previously checked in his changes (to graphicsdriver.cpp) without testing or even compiling them. As Bob's and Wendy's views share the same configuration, when Bob checks in his changes to graphicsdriver.cpp, Wendy's view may be updated to select the new version. Because Wendy can test her system only if she compiles both graphicsrendering.cpp and graphicsdriver.cpp, her work could be halted by Bob's lack of attention to quality: graphicsdriver.cpp might not compile, or it might cause the system to fail immediately upon execution (Figure 3).
让我们假设Bob和Wendy都是被指派进行图形工作的，并且已经划分了各自的工作任务：Bob做活动263，Wendy做活动 264:优画图形透视效果（图2）。Wendy决定 活动264需要修改graphicsrendering.cpp文件，于是她检出该文件并做了修改。Wendy，作为一个细心的开发人员，她决定测试这些变更。为执行这个测试，她试图构建软件，但泄气的是，Bob在此之前已经检入了他对graphicdrivers.cpp的变更，不仅没有测试，甚至没有编译过。由于Bob和Wendy共享一个相同配置，当Bob检入他对graphicsdriver的变更，Wendy的视图可以被更新到这个新的版本。因为Wendy只有在编译了graphicrendering.cpp和graphicsdriver.cpp后才能测试她的系统，她的工作可能由于Bob对质量的疏忽而被中断：graphicsdriver可能不能编译通过或者可能导致系统一运行就立即失败。（图3）
To address this situation, Wendy and Bob could create individual streams, based on the same foundation as the Graphics Changes stream. Their individual changes would then be entirely isolated from each other, and Wendy's productivity would not be hampered by Bob's lack of attention to detail (Figure 4).
为解决这个问题，Wendy和Bob各自基于图形变化工作流建自己的工作流，他们各自的修改完全和对方的修改隔离，而且Wendy的开发效率也不会因Bob对细节的疏忽而受影响。
图4：两个开发人员使用独立的工作流 This is detail; let's take a quick step back and look again at the big picture.
We have seen that the big advantages to using streams and UCM are that you can:
l l Quickly propagate a bug fix or enhancement to all product variants that need it.
Improve the productivity of individual developers.
However, we have been using simplified examples that don't touch upon some of the complexities of larger software projects. We'll discuss scaling up in the next section.
这就是详细的过程，让我们快速回顾一下并重新看一下大图。我们可以看到使用工作流和UCM的最大好处是你可以：
快速将一个Bug修复或优化功能传递到所有需要此功能的差异性工作流中
提高每个开发人员的开发效率。
然而，我们只是使用了简化的例子，在这个例子中没有触及大型软件项目的复杂问题。我们将在下一节中讨论更深入的内容。
文章来源于领测软件测试网 https://www.ltesting.net/
