查看完整版本: 如何理解“基线”（Baseline）这个术语【转】

如何理解“基线”（Baseline）这个术语【转】

转载自：[url]http://www.devmanclub.com/ShowPost.aspx?PostID=1637[/url]


--------------------

“基线”是一个很常见的术语，在配置管理和项目管理里面都能看到，而且还有很多衍生的术语，例如基线提升、基线化、基线审计，等等等等。

我个人以前对微软的那套开发流程（就是product cycle model）以及PSP、TSP了解比较多一些，这些流程里面对“基线”的概念提的不多。但接触RUP、MSF以及项目管理以后，看到到处都有b
aseline，就觉得迷惑了。

经过我自己的理解，以及和几个同事的讨论，现在我觉得我们通常看到的“基线”这个术语有两个意思：

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，就是在做基线。

这种基线对“构建审计”特别有用：在做build的时候，可以先对所有源文件做一个label，取名为"Build2394"，然后再编译、集成。这样，以后如果要找到和build 2394对应的原文件，只需要
到vss或者cvs里面把所有文件对应label Build2394的版本取回来就可以了。

2）代表文档的一个稳定状态。

比如有一个项目设计文档，当设计基本完成，开发即将开始的时候，需要把这个文档固定下来，内容不能再频繁改变，否则开发人员就无所适从了，可能导致每个人所参照的文档并不是同一个文档。用一句上海这里的生活用语来
说，就叫做要把这个文档“敲定”。

一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被“基线化”了，然后所有人就可以在这个“基线”的基础上工作。

当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既然是“基线”，就不能随便动。

但是到了一定时候，修改积累到一定程度，就需要把很多修改合并到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的参考标准，并把老的版本淘汰掉。这就叫做“基线提升”。



以上就是我个人对“基线”这个术语的两种不同含义的理解，大家可以讨论讨论看，是不是差不多就是这个意思。
3)合同基线
当你和客户讨论后，“敲定”的合同
4）发行基线
你会对你要发行的代码，文档版本进行label, 比如Release2.2,
这样，你可以随时取出此版本作build，进行测试，发布。

5）产品基线
当发布时，你会对产品中所有的配置项进行label,包括可执行命令，文档手册，库文件。。。

谢谢

thanks

好东西！感谢！

基线(Baseline)说起. 基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.

      基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。

      参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。

      建立基线的三大原因是：重现性、可追踪性和报告。

      重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布说明。

      建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。

      建立基线有以下几个优点：

      基线为开发工件提供了一个定点和快照。
      新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
      各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
      当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
      您可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。

      使用

      定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点（次要里程碑），以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：

      生命周期目标里程碑（先启阶段）
      生命周期构架里程碑（精化阶段）
      初始操作性能里程碑（构建阶段）
      产品发布里程碑（产品化阶段）

基线和label有略微的差别，从流程上来说，基线更加正式，有严格的控制流程，是某些有特定意义的label；而建立label相对要随意些，可以直接由项目经理控制，觉得某个版本比较稳定，就可以建立label。基线是属于label的子集。当然，实际操作中把两者合二为一问题也不是太大。

学习中。。。。。。。。。。。。

谢谢，很经典，了解！！

:lol :lol :lol
终于明白了baseline了,THX!