控制跨多個差異性的變更
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.
讓我們深入了解一下建立這種管理機制的具體細節。首先，開發人員創建一個新的視圖，提供修改目錄和文件的工作空間，同時可以構建和測試這些修改。他既可以選擇圖形變化工作流或要求創建另一個新的工作流�，F在，讓我們假定他使用圖形變化工作流。
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修復或優化功能傳遞到所有需要此功能的差異性工作流中
提高每個開發人員的開發效率。
然而，我們只是使用了簡化的例子，在這個例子中沒有觸及大型軟件項目的復雜問題。我們將在下一節中討論更深入的內容。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
