全球最资讯丨软件文档中的“基线化”是什么？提升文档基线的8种方法

1) 基线：

(资料图)

代表多个源代码文件的一组版本。比如有三个文件，aaa.c、bbb.c和ccc.h。可以对这三个文件做一个基线，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一个基线。换句话说，通常在vss和cvs里面做label，就是在做基线。

2) 基线提升：

一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被“基线化”了，然后所有人就可以在这个“基线”的基础上工作。当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既然是“基线”，就不能随便动。但是到了一定时候，修改积累到一定程度，就需要把很多修改合并到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的参考标准，并把老的版本淘汰掉。这就叫做“基线提升”。

4)发行基线你会对你要发行的代码，文档版本进行label, 比如Release2.2,这样，你可以随时取出此版本作build，进行测试，发布。5)产品基线当发布时，你会对产品中所有的配置项进行label,包括可执行命令，文档手册，库文件。。。

8) 基线(Baseline)说起. 基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并 且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更 一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。建立基线的三大原因是：重现性、可追踪性和报告。重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。 其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布 说明。建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。建立基线有以下几个优点：基线为开发工件提供了一个定点和快照。新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。您可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。使用 定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点(次要里程碑)，以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：生命周期目标里程碑(先启阶段)生命周期构架里程碑(精化阶段)初始操作性能里程碑(构建阶段)产品发布里程碑(产品化阶段)

区别对待缺陷和新增功能

通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修 复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个 紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。

我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发：

Øv1.0中的缺陷修复

Øv1.0的新增功能版本v1.1

Ø下一个版本v2.0

***********************************************************************************

发布版本构建(build)而不是源代码

这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。

由于软件构建的结果很可能会受构建平台及相应编译器版本所影响，最终在生产系统上的运行代码(在生产系统上构建得到)与准生产环境上的运行代码(在准生产环境上构建得到)可能不完全一致，有可能造成质量隐患。比较通行的做法是所有平台上运行的构建代码应该只在构建服务器上生成一次，一次编译到处运行，这样才能保证各个平台上所用到的同版本运行代码是同一次构建的产物。

版本发布管理

对于所发布的构建版本，我们也需要进行有序的管理，可以用版本号来唯一标识每一个发布版本。一 般可以把用于开发团队内部系统测试的称之为内部发布版本，把提交给客户的称之为外部发布版本，这两种软件发布版本都要统一编号管理。在我们的例子中，内部 发布版本可以简单地用构建号来表示，如：

v1.0_build_008表示版本v1.0开发过程中生成的第8次构建外部发布版本可以由版本号和发布号组合而成，如：

v1.0_rel01表示版本v1.0的第一个外部发布版本

对于v1.0中的缺陷修复，我们可以通过补丁的方式来发布，一个补丁中可以包含有多个缺陷修复，被修复的缺陷需要在补丁的发布说明(Release Notes)中写明，补丁名称可以由版本号、发布号和补丁号组合而成，如：

v1.0_rel01_p001表示针对发布版本v1.0_rel01的第001号补丁

对于v1.0中新增功能，我们需要制定一个发布计划，根据客户新增功能请求的紧急程度来分期分批实现，一次发布中可以包含多个新增功能，并且包括所有已改正的软件缺陷，这些改动都必须在发布说明中写明，发布版本号可以在前一个发布版本的基础上递增，如：

v1.1_rel02表示版本v1.1的第二个外部发布版本

对于下一个版本v2.0的开发，则与版本v1.0开发的发布管理完全一致，如：

v2.0_build_002表示版本v2.0开发过程中生成的第2次构建

在版本发布管理的流程中，发布版本的安装应该由专门的角色负责，可以是配置管理员或者是集成员(integrator)；开发人员被禁止向各平台(测试平台、准生产环境、生产系统)上安装任何软件，并且各平台上所安装软件的版本号.0.0 Notes 11都应该有详细的记录。当软件缺陷被发现时，我们就可以明确知道问题究竟是出在哪一个版本。

内部发布版本只会被安装到测试平台上，经过 “开发à 构建à测试à 发现缺陷à 修改代码” 的多次循环之后，内部发布版本的质量趋于稳定，开发团队才会决定做一个外部发布版本。

外部发布版本被安装到准生产环境上，并且只有通过用户验收测试，它才可以被安装到生产系统上 去。如果该版本没有通过用户验收测试，那么开发团队需要提供相应的补丁来解决用户验收中发现的问题，直到通过用户验收后再将该发布版本及其所有的累积补丁 全部安装到生产系统上去。有些情况下，最终通过验收测试的也可能是下一个发布版本，所以生产系统上安装的发布版本前后之间不一定是连续的，中间可能跳过一 些质量不够成熟的版本。

同样的，只有通过用户验收测试的补丁才会被最终安装到生产系统上去。紧急的补丁经过用户验收测试之后会马上安装到生产系统上，不紧急的补丁可以累积几个以后批量安装上去。