摘　要：从软件配置管理应用中版本控制常面临的问题出发，与传统软件配置管理分支模型比较，说明基于目的分支的软件配置管理模型能更好地支持并行软件开发和软件发布控制。

关键词：软件开发；配置管理；分支模型

Software Configuration Management Based on Branching Models

CAO Ying

（Southwest China Institute of Electronic Technology,Chengdu 610036,China）

Ａｂｓｔｒａｃｔ：According to the problems arising from the version control in software configuration management application, this paper demonstrates that the software configuration management model based on branching can better support parallel software development and software release control in comparison with traditional software configuration management branching model.

Ｋｅｙｗｏｒｄｓ：Software development; Configuration management; Branching model

一、引言

在软件开发的整个生命周期过程中，需要不断地修改软件。为了对这些修改和变动进行有效管理以免造成开发过程的混乱，需要进行软件配置管理。

软件配置管理是一套管理软件开发和软件维护及过程中各种中间软件产品的方法和规则，配置管理通过系统地管理软件配置项和控制对配置项的修改，在整个软件生命周期中维护配置项的完整性和可追踪性。

在软件开发实践中，常常出现一些令人沮丧的事，如软件紧急更改提交集成失败、发布错误版本、修复过的缺陷又莫名其妙地出现等等。是什么原因导致这些挫败？是代码太大、太复杂？还是并行开发的固有问题？或者只是因人员调整、进度紧迫带来的问题？研究表明，上述因素都有可能引发软件错误，但不是主要的原因，而主要的原因在于在实际开发中没有应用软件配置管理或应用软件配置管理不当。

只有深入地认识软件配置管理，才能正确应用。对配置管理模型的研究，有助于理解和认识配置管理中的一些问题和矛盾冲突，进而应用适合实际需要的配置管理模型。应用正确的分支模型，对避免开发过程的混乱尤其重要。

二、软件配置管理及分支模型

软件配置管理（Software Configuration Management）包括配置标识、版本控制、变化控制、状态报告和审计控制四部分。配置标识是在系统演化过程中标识过程中的中间软件产品，版本控制记录每个配置项的发展历史，并控制基线的生成，变化控制包括在整个生命周期中控制中间软件产品的变化，状态报告指记录和报告软件的变化过程，审计控制保证软件过程遵循要求和标准。从实际操作的角度来讲，软件配置管理具有两方面的功能：其一，支持对软件产品的变更控制管理，该功能包括与ＳＣＭ有关的传统活动，包括确定软件构件、控制对这些构件的更改、记录和报告构件和配置状态以及进行审计和评审；其二，支持开发人员对文件的同步更改，这类活动包括确定文件版本、软件构建管理和版本发布管理。

软件分支是软件版本控制、软件构建管理和版本发布管理的重要组成部分。运用分支使得并行开发新的系统、同步更改多个并行版本的错误、同时集成和发布多个版本称为可能。分支模型包括了将配置项复制到多个实例中所采纳的基本原理，每个配置项都有唯一的且恰当的配置标识。

版本控制是配置管理的基本要求，它可以保证在任何时刻恢复任何一个配置项的任何一个版本。版本控制还记录了每个配置项的发展历史，这样就保证了版本之间的可追踪性，也为查找错误提供了帮助。版本控制也是支持并行开发的基础。版本的演变有串行演变和并行演变两种方式。在串行演变的方式下，每一个新版本是由当前最新版本演变而来的。各版本按演变过程形成一个版本链。串行演变形成的一维的版本，称之为修订版本（Revision）。这种演变方式是按一对一的映射关系进行的。在实际的软件开发过程中，版本演变多是采用一对多的方式进行的，称之为并行演变。并行演变形成二维或更高维版本，称之为分支版本(Variant)。

版本在演变过程中，有一些版本需要合并以减少冗余。版本合并包括水平合并与垂直合并策略。水平合并时，不同分支版本代表不同的开发流，不同的开发流要合并在一起，就需要将源分支上的最新版本合并到目标分支的最新版本中，并在目标分支上产生一个新的版本。垂直合并是为了控制版本的增长，在原子构件的一个分支上将相邻的若干版本合并为一个版本。

正确地选择何时和以何种方式进行分支可使开发和构建人员更好地控制软件变更。选择正确的分支策略使版本正确发布、重构以前的版本或者重新回到以前的版本等工作更加容易。采用分支模型使软件开发过程更加便捷、软件开发更加高效、软件质量得到提高，并且可以减少软件开发中的错误和提高软件开发团队的整体效率。要选择适当的分支模型，应从以下几个方面考虑：
　　（1） 支持连续不间断的集成，从而保持新开发过程的稳定的基准；
　　（2） 提交应急版本（只包括所有必要的修复）进行测试和交付用户；
　　（3） 包含有所有必要的修复而无其它更改的测试版本发布；
　　（4） 使应急发布对新开发过程的影响最小化；
　　（5） 必要时，回退到以前的产品状态；
　　（6） 现场支持多个连续版本；
　　（7） 支持多个共存版本，如不同平台或不同用户的备选版本。

三、发布分支模型

传统标准以一系列连续的基线来管理软件配置。发布分支模型的代码管理就是这种方法。在这种传统模型中，发布工程师提交一个新版本时，建立一个新分支，该新分支作为继续开发的基线，如图1所示，旧分支包括已发布的版本，亦即实际的历史基线参考点。该分支被遗留下来，不再起作用。

发布分支模型提供SCM按惯例所需要的一系列连续基线，为开发人员提供了更改代码时可采用的共用基准。但是，它有两个明显缺点：要求顺序更改代码，如顺序检入和检出，而不能并行开发；增加了对已发布版本的维护复杂性和费用。

发布分支模型很容易理解，但修复老版本软件的缺陷很可能丢失在后续版本中执行的更改。只要存在产品维护，就有缺陷修复和进行应急发布的可能性。在这种情况下，开发人员必须在老分支中进行修复并依此产生新版本。这看起来很简单明了，但要保证修复的缺陷不再出现在后续版本的操作很复杂，因为开发人员必须将该缺陷修复传递给各后续分支，以保证后续的从来没有修复该缺陷的工作流版本中不再出现该程序缺陷。

隔离更改并确认将每个缺陷修复都传递给所有后续版本会增加交流和协调负担。当开发人员从一个开发流转到另一个新版本的开发流时，环境在不停地发生变化。发布分支模型不支持长期的并行开发发布周期，在发布之前，所有检出的代码必须再检入。如果开发人员在发布之前不检入所有的代码，那么在发布后，该模型方式就不允许代码从头构建。每当开发人员在发布后检入更多更改时，发布工程师就必须保证这些未经测试的更改不会并入由该工作流创建的后续各新版本中，这些新版本可能因诸如应急发布之类的原因发布。由于没有从头构建，大大地增大了应急发布错误构件的风险，因此这种发布特别容易出问题。这也破坏了整体基线概念，因为，从未对外发布的更改进入了基线代码。

发布分支模型也不能维护多个并存版本。

在发布分支模型应用中，经常按缺陷管理构建，容易引发称为缺陷构建综合症的问题。图2显示了按缺陷构建所面临的困难。发布工程师必须手工确定与指定缺陷修复相关的代码并确保只有该修复相关的代码进入发布构建。在这种模式下，版本控制工具要求必须将代码检入到原先检出的同一工作流。如果开发人员在发布软件产品之前没有将代码检入回去，就不能将该代码直接用于下一个版本的工作流。必须首先执行这种回原工作流的滞后检入，然后再合并到后面的工作流。否则，要求开发人员放弃这些更改并在新的开发流重新更改。

四、目的分支模型

图3所示的目的分支的模型，是一种改良的配置管理模型。利用这种模型，发布工程师可根据特定目的在不影响主要开发流的情况下创建新的专用目的分支。通常，“目的”包括在开发团队之外发布软件及其相关组成元素（如文档）。通常这些发布工作都是工程进度的重大的里程碑标志，如用于Alpha测试或Beta测试等目的进行的QA发布。

目的分支模型既支持根据常规发布，也支持根据需要进行的受控的紧急发布，它避免了发布分支模型的缺陷构建综合症。目的分支模型可以满足所有的典型的评价标准。该模型还简化开发。开发人员可以工作在相同环境的主要开发分支下，减少了开发团队成员关于在哪儿执行更改的疑惑，使紧急发布更健壮，减少了代码冻结对于团队工作的影响。

分出一个新的发布分支而不分出一个新的工作分支，避免了发布分支模型的代码冻结，有利于工作进展。因为代码冻结使他们无法检入正在进行的工作，推迟代码冻结通常会导致压缩测试周期、降低发布产品的质量。

目的分支模型管理要复杂些，主要是因为它要求更为深入地了解SCM和更熟练地使用SCM工具。但这种模型提供了便捷的方法，正如前面所述，发布工程师为发布产品衍生出一个新的分支，而开发工作仍保持在主要开发流上。

发布工程师可以产生一个QA分支用于发布QA测试产品。一旦开发和测试人员完成了缺陷的发现和修复工作，发布工程师就可以发布产品。发布新版本时，发布工程师建立一个特定生产流分支，该分支的唯一目的就是支持发布。

目的分支模型假定产品发布周期中有一个里程碑点，到达该点，开发人员不再增加新功能，也不进行未经评估和控制的改进。该里程碑点标志着开发工作已进入代码冷冻阶段。在代码冷冻期间，开发人员在开发流进行缺陷修复并定时发送新版本给QA。每个QA发布版本都有一个对应的分支，方便验证缺陷是否修复及缺陷是否出现在之前QA发布版本中，也方便标识发现缺陷的版本和修复缺陷的版本。

软件通过测试周期，逐渐稳定，修复工作逐渐减少，可实现代码冷冻到代码冻结。在代码冻结里程碑点，即使该版本只是候选产品，也必须进行最终测试，以确保其可以用于生产，开发团队可假设产品已准备就绪可以用于最终的生产。从这个里程碑点开始，开发人员直接将经更改控制委员会（或工程管理团队）批准了的缺陷修复直接加入到对应的QA分支并合并修复结果到主要开发流。待测试人员验证确认变更代码库正常运行之后，发布工程师就可以发布用于生产的产品并建立生产分支。当外场发现缺陷需要发布紧急版本时，开发团队可以采用同样流程，如图3所示的“产品1.1”。

五、支持并行开发

快速开发流行趋势要求进行并行开发。软件项目必须边改进边发布。为了满足并行开发的各种需要，可以建立临时桥接流，一条用于待确定的缺陷修复，一条用于系统改进。也可以只建一条桥接流，既用于缺陷修复又用于系统改进。在候选产品发布后，就可以合并到开发流。

在发布分支模型中，当正在进行的代码变更必须延迟到发布之后时，就会出现问题。对于孤立的、没有纳入发布的检出，开发人员陷入了两难境地：要么，将更改过的代码检入到原检出流，这就意味着要将其放入发布产品的分支，而该分支不包含此代码，这就破坏了分支的完整性，然后将其合并到一个新的发布分支中；要么，从新分支开始重新检出，重新更改，再检入到新分支，这又引起不必要的重复。

目的分支模型可以解决这种矛盾，如图4所示，因为主开发流没有改变，开发人员可以检入代码到其被检出的主工作流，并且将其纳入即将发布的产品发布周期。用于发布产品版本1.1的代码库仍保持不变，因为它归属于自己的分支。

在目的分支模型中，在发布代码冻结后，开发者只能检出代码到主开发流，而不影响发布代码并保持其完整性。

目的分支更易于满足多个团队并行地工作在多个子项目的复杂情况的需要，分支可以建立完全重复的环境，这种环境下开发人员可以在不影响其它同在一个代码库中进行开发的代码修改和变更测试。建立小的、有目的的、交替的开发流，让开发人员检入代码到适当的临时流，不影响主开发流。

并行开发概念允许频繁地将更改从一条开发流合并到另一条开发流，目的分支模型能照顾到该需要，SCM和发布流程可以管理这些合并操作，使它们尽可能地不增加操作负担。

与之相反，发布分支模型的操作基于各版本是线性的和连续的、每个后续版本是其前一版的延续的假设，因此对现存基线版本或之前版本进行更改集成都不太容易，实现这些更改需要付出特殊努力来保证任何老版本的新发布都只包含期望的更改（通常是缺陷修复）而没有其它的更改，而且要求发布工程师正确地将这些更改合并到新的、正在工作过程中的版本以及老版本与当前版本之间的所有版本。

在目的分支模型中，开发人员建立一条单独的构建主流，在预先确定的时间发布一个产品的新版本，发布工程师建立单独的分支。这种方式允许频繁地在代码主流上从头构建，涵盖所有实现了的更改。如今软件公司最推崇的方法都强调通过从头构建实现频繁的集成。这种构建随着测试人员和开发人员的工作结果检入逐步集成更改，可以连续不间断地构建，直到发布周期结束。这种方法确保了连续的集成并避免了项目组推迟集成引起的大量矛盾的更改可能产生的冲击。

在完全相同的环境下修改代码，可以连续地进行每条工作流的构建并对更改进行深入的测试，而不影响开发主流。可实现多个开发人员同时对多个代码因多种目的进行多种更改。目的分支模型的变体可以适应各种情况。

六、结束语

尽管发布分支模式应用广泛，而且很严格地执行顺序基线的传统标准，但发布分支模型在开发新版本时对已发布的软件老版本维护困难，容易出错，通常需要手工修复已发布软件。它的主要缺陷还包括对已发布代码修复的管理方面的不必要的复杂性，以及在过程中进行不必要的孤立更改，影响集成进度。

目的分支模式避免了这些缺点。该模式还提供了结构化的机制管理多路工作流，支持提交多个发布版本，并能满足应用并行开发和持续集成的方法来缩短开发周期的需要。

由此可见，在软件配置管理的分支模型中，基于目的分支的模型更有利于并行开发，既可改善软件常规发布控制，也可改善应急发布控制。基于目的分支的配置管理模型值得推广应用。