使用UCM工作流简化产品线开发（一）

原文标题：Simplifying Product Line Development Using UCM Streams
  Many organizations struggle with the complexity inherent in developing a product family. This complexity can be partially managed by maintaining a strong focus on system architecture and program management techniques.Concentrating on the configuration management discipline, this article explains how the Unified Change Management (UCM) concept of streams can help organizations support multiple product family projects by reducing start-up timeframes, tracking changes, managing dependencies between product variants, and propagating changes between product variants.
  在开发一个产品线时，许多组织为其内在版本的复杂性所困。通过重视系统架构设计和项目管理技巧可以部分解决这个问题。本文侧重于从配置管理的角度，解析统一变更管理（UCM）中工作流的概念如何通过减少启动时间，跟踪变更，管理变更在不同产品中的依赖关系，并在产品间传递这些变更，以支持多个产品线项目的开发。
  In typical product line development, several variants of a product are under development simultaneously. This can happen for any -- or sometimes all -- of the following reasons:
  1、Products with the same basic architecture are needed to provide
different end-user services/functionality.
  2、The same product needs to be deployed on different target
platforms (hardware or software).
  3、Older versions of the system need maintenance support.
  4、Development timeframes for multiple versions overlap; for example, Version 2 might still be under development when development of Version 3 is slated to begin.
  在典型的产品线开发中，一个产品的几种差异性版本会被同时开发。这种现象往往出现在以下任一个---或所有条件都满足时：
  1、具有相同的基础架构的产品需要为不同的终端用户提供服务/功能
  2、相同的产品需要在不同的目标平台上部署（硬件或软件）
  3、老的系统版本需要进行维护
  4、多个版本的开发时间跨度出现交叉重叠，比如，版本2仍在开发，但版本3已经 准备启动。
  The simultaneous development of multiple variants presents a significant
challenge to the configuration manager: There is a delicate balancing act
between the need to share desirable changes across all variants and the
need to keep firm control over the configuration of a given product.
  In the modern software development environment, the scope, frequency,
and volume of change, coupled with continually increasing system size and
complexity, makes change tracking extremely difficult, even for a single
project. With variants, this task becomes even more difficult. One way to
tackle it is by adopting the advanced configuration management practices
detailed in Rational's Unified Change Management (UCM)1 approach.
  Based on studies of software development projects in a range of highly
effective organizations, UCM was developed to help codify and automate
change and configuration management best practices. It is implemented
with the Rational? ClearCase? software configuration management tool.
By applying the UCM concept of streams, organizations can efficiently
develop variants, even in large-scale systems. Streams allow different
project teams to work on a common set of artifacts independently, sharing
changes only when it is desirable to do so.
  同时开发多个差异性版本给配置经理提出了一个严峻的挑战：在满足不同差异版本间变更共享的同时，继续保持对指定产品的严格配置控制，这需要一个巧妙的平衡。在现代的软件开发环境中，变更的范围、频率和数量随着系统规模和复杂性的增长而不断增长，使即使只追踪单个产品的变更都非常困难。再加上多个差异性版本的存在，变更追踪就更为艰难。Rational统一变更管理（UCM）提供了解决这个难题方法，它详细阐述了先进的配置管理实践经验。UCM是在对大量高效开发组织的项目研究的基础上，为帮助编码、自动变更和配置管理而开发出来的配置管理最佳实践。它使用Rational ClearCase软件配置管理工具实施。通过应用UCM工作流的概念，组织可以有效地处理差异性，对大规模的系统也游韧有余。工作流允许不同项目团队独立工作于同一套软件工件，只在需要的时候共享变更。
  Managing Change
  管理变更
  In a software development environment, we can classify changes aclearcase/" target="_blank" >ccording to two levels of granularity:
  1、Microlevel, day-to-day changes that individual developers make to a
component or set of components (e.g., bug fixes or small
enhancement requests).
  2、Macrolevel changes that add significant new product capabilities to
the system.
  在软件开发环境中，我们可以把变更分为以下两类级别：
  1、微粒级，每个开发人员每天都要对组件或一系列组件进行的变更（比如，Bug修复或小的变更请求）
  2、粗粒级，新增的主要产品功能。
  When planning development of a new product variant, it is convenient to think in terms of extending capabilities. We would specify a variant in terms of adding a new set of capabilities to the existing set of capabilities provided by a product framework. We may distinguish between the macrolevel and icrolevel in a number of ways, but it is perhaps easiest to categorize macrolevel changes as those that are visible from a project management or end-user viewpoint: key features, performance improvements, and so on.
  当规划新产品差异版本开发时，从扩展功能的角度去考虑更方便些。我们以新增一系列新功能到已有产品框架功能来界定一个产品的差异性。我们可以通过多种方式区分粗粒级和微粒级变更，但也许最容易区分粗粒级变更的方式是从一个项目管理者或最终用户的角度去看整个系统的功能：关键功能，性能优化等。
  That said, management of microlevel changes is still very important.
  Customers hate nothing more than to see old defects find their way back
into a release. You also want to be efficient about ensuring that bug fixes
and small enhancements are propagated across all product variants. A common practice within more advanced software development environments is to create and maintain an architecture with a set of components that do not need modification from one product variant to another. This is usually realized by a layered architecture: Perhaps a "business" layer provides components that automate business logic common across each variant. Similarly, a "system" layer might provide a set of components that perform lower-level functionality (e.g., operating system interfaces, hardware interfaces, middleware interfaces, etc.) that is invariant from one project to another. Unfortunately, it is still possible -- and even likely -- that a component might need to be modified for some, or even every, variant in any of the layers. For instance, there might be
subtle modifications in the business logic between projects, or a requirement to support new computing hardware. In this situation, it is much better to automate (or at least partially automate) the propagation of required changes to the relevant variant, than to have to make these changes manually.
  也就是说，管理微粒级的变更将更为重要。用户最讨厌的莫过于看到老的缺陷又出现在新的版本中。你也同样希望可以确信Bug修复和小的变更请求可以在所有产品差异性中都得到修复。在更高级的软件开发环境中,常用的实践是创建和维护一个具有一系列组件的系统架构，这个架构中的组件不需要在每个产品差异版本中修改。这通常被公认为分层架构：“业务层”可能包含自动实现了不同产品间相同的业务逻辑的组件。类似的，“系统层”可能提供一系列执行底层功能的组件。（如操作系统接口，硬件接口，中间层接口等）这些底层功能在不同产品间没有差异。但是，仍然有可能，并且极有可能—个组件需要在某一个，甚至所有层中进行修改，并且每一层中都不相同。举个例子，不同产品间可能在业务层存在微小差别，或者需要支持新的计算机硬件。在这种条件下，自动化（或至少部分自动化）传递相关差异版本间必要变更比不得不手工修改要好得多。
  So, in summary, the goals of change management for developing product variants are:
  1、Specify variants in terms of adding new capabilities to an existing set of selected capabilities.
  2、Manage change at the microlevel and macrolevel ("product capability").
  3、Streamline the management of microlevel changes.
  Let's explore how to use UCM (see definitions in the sidebar) by working
through some scenarios.
  所以，总的来说，产品差异性变更管理的目的是：
  1、根据是否新增功能界定是否是差异性
  2、在微粒和粗粒两个级别上进行管理
  3、将微粒级的变更管理流线化（参见侧栏内定义）
  让我们通过演练以下几个场景看看如何使用UCM
  Setup for Variant Development
  搭建差异版本开发环境
  Imagine that a development organization wants to port a system from a UNIX platform to MSWindows, while continuing to support their UNIX-based customers. This is an example of a variant.
  假设一个开发组织想将一个系统从Unix平台迁移到MS windows平台，同时继续支持使用Unix平台的客户。这是一个差异性例子。
  Project setup for variant development is a major hurdle for many software organizations. The first issue is often that they do not understand the need for robust configuration management practices to support variants. The organization might maintain multiple repositories (one per variant), each with slight differences -- and no one really understands what these differences
are.
  创建支持差异性版本开发的项目环境是众多软件开发组织的主要障碍。主要问题是他们常常不清楚这需要一个强大的配置管理实践来支持这些差异性开发。软件组织可能同时有多个存储库（为每个差异性分配一个库），每个库都有着细微的差别，但没有人真正清楚这些差别在哪。
  Under these circumstances, the only way to propagate changes across variants is through "Copy and Paste." Changes to copied data then need to be maintained in each repository. But no one knows which repositories already have the change
and which do not. Ensuring a high quality product release will require a large amount of tedious and time-consuming inspections and adjustments.
  在这种情况下，唯一的办法是通过“拷贝、粘贴”的方式传递变更。修改的数据需要逐一更新到每个存储库。但没人清楚哪个库已经做了更新，哪些没有。因此，为保证高质量的产品发布，需要耗费大量的人力和时间进行仔细检查和校对。
  A second issue is that, to start development of a variant with an existing set of artifacts, the team leader and/or architect must define a starting point for the development team and in many instances they choose component versions, rather than versions of individual files. This complicates project setup: It is not sufficient to track only component versions, because each variant might
modify the same component. For example, specifying Version 5 of a file management component is meaningless if there is a Version 5 for the UNIX platform variant and a different Version 5 for the Windows platform variant
  第二个问题是，在原有工件的基础上开发新的差异性，团队负责人和/或系统架构师必须为开发团队定义一个起点。而在很多情况下，他们会选择组件版本，而不是单个文件的版本。这将使得环境的搭建更复杂：只跟踪组件版本是不够的，因为每个差异性版本都可能修改同一个组件。比如，只指定一个文件管理组件的版本5是没有意义的，如果同时有一个  Unix平台差异的版本5和另一个不同的Windows平台差异的版本5。
Before starting work, development teams need to consider the following:
  1、What is the quality of the initial component versions? Preferably, only well-tested and approved changes should be included in the foundation for the new project, so that the project team can avoid spending time on resolving broken builds. So, the team needs a way to quickly select just those component versions that have undergone appropriate levels of quality assurance.
  2、What are the relationships between component versions? A component often has dependency relationships with several other components, so an incorrect set of component versions could cause integration problems. This means that a configuration management approach that focuses exclusively on components while neglecting their relationships is sub- optimal.
  在开始工作前，开发团队需要考虑以下方面因素：
  初始组件版本的质量如何？最好是只把经过完全测试并通过批准的变更包含到新项目的基础版本中，以免项目成员浪费时间去解决构建失败的问题。因此，开发团队需要有一种方式可以很快地选择到那些已经达到质量保证的正确级别的组件版本。
  组件版本间是什么关系？一个组件常常和其他几个组件有关联，因此一组不正确的组件版本将会导致集成问题。也就是说，一个只关注组件而忽略它们之间关系的配置管理方法并不是最佳的。
  Large projects can spend an enormous amount of time determining the answers to these questions, so what is needed is a streamlined approach. Using UCM streams represents a very efficient approach. Each stream specifies the right version of every file. This greatly reduces the need to track file or component versions, and the dependencies between these versions, because the stream represents the foundation for a project in terms of a single entity.
  规模大的项目将要花大量的时间去寻找这些问题的答案，所以我们需要的是一个流线化的方法。使用UCM工作流是一种非常有效的方式。每个工作流配置各个文件的正确版本。这大大减少了追踪文件或模块版本，以及这些版本之间的依赖关系的时间，因为工作流以单个实体的方式组成了项目的基础。
  Of course, a developer might not want the latest changes made in the stream if they have not have been tested. UCM streams have a baseline to record their configuration at a point in time, so the team lead can select not only a stream, but also a baseline within that stream, to provide a stable foundation for team members to work from. The stream concept represents a change in mindset for many experienced software configuration managers, most of whom are used to thinking of baselines as versions of components. But UCM extends the concept to improve efficiency: It defines a baseline for a stream, which in turn defines baselines for the components in that stream.
  当然，如果工作流上的最新版本还未经过测试，开发人员可能不想要这样的版本。 UCM工作流用基线来记录在某个时间点的配置，因此团队负责人不仅仅可以选择工作流，还可以选择工作流上的基线来给项目成员提供一个稳定的版本，做为开发的起点。工作流的概念体现了大多数经验丰富的软件配置管理员认识上的一个改变，他们中的许多人习惯把基线当作是组件的版本。但UCM扩展了这个概念并提高了效率：它定义了工作流的基线，这个基线反过来定义了这个工作流上组件的基线。
  With this stream-based approach,larger projects can use UCM components -- rather than a myriad of small logical components – to represent large subsystems.
  通过这种基于工作流的方法，更大的项目可以使用UCM组件—而不是无数的小逻辑组件---来组成大的子系统。

原文转自：http://www.ltesting.net