查看完整版本: 基线的含义：一步一个脚印……

基线的含义：一步一个脚印……

Baseline（基线）是一个容易让人困惑的概念。为啥容易困惑呢？往深了说，有文化方面的因素…… Baseline是他们欧美人常用的一个概念，远不止在SCM领域…… 咱还是往浅了说吧……

即使在SCM领域，Baseline也有相互间略有区别的几种含义。

第一种，最常见，指源代码树的Snapshot（快照/断面）。当然，不是任意时刻的一个Snapshot都是Baseline。基线通常意味着，首先，被明确的标识出来，将来可以复现，比如用一个Label/Tag（标签）标识；其次，达到了一定的质量级别，比如，编译通过了，或者粗略测试通过了，或者系统测试通过了。这样，基线就好像脚印。只有踩实了这一步，才去迈下一步…… 如果项目不大，清清爽爽，一切尽在掌握中，你可以蹦蹦跳跳。但是，在上规模的项目中，在深浅未知泥潭里，还是稳一点吧……

第二种，指一份文档的某一个版本。这个版本，质量比较好，没啥错误或者前后矛盾的地方。相关的同志也都看过了，一致同意，都点了头。那么，这个版本就作为基线了。大家以后都要遵守。如果是需求文档，那就轻易不要变了，要根据它做设计。如果是设计文档，那就轻易不要变了，要根据它做实现…… 这里，基线有点儿像结婚…… 也就是说，真不成，也能离婚…… 轻易不要变，万不得已还是可以变的，只不过变起来比较麻烦，得先再次征得相关同志的一致同意（一般来说）……

第三种，不是一份文档了，而是一个项目的“所有的”文档和“所有的”源代码在一起的一个断面。这个断面，除了要保证有一定的质量外，更重要的是，1. 达到了某个阶段性目标，比如，系统设计完成，或某个重要功能实现。2. 基线内，各文档间，文档与源代码间，是一致的。文档上说，点一下按钮，蹦出三只红眼睛兔子，那源代码就要实现蹦出三只红眼睛兔子，四只是不行的，绿眼睛是不行的，耗子也是不行的…… 通常，这样的基线，就可以对应到项目的Milestone（里程碑）上了。

从频度上说。第一种基线通常比较频繁。可能一两周一个，也可能一两天一个。第二种基线，每个文档可能只有一个，也可能后来有修改，有又几个。第三种基线，数量有限的几个，通常是项目起始时就计划好了。

就写到这儿吧。原创。难免有偏颇的地方。还请大家多多指教，一起交流！

[[i] 本帖最后由 流水先生 于 2007-2-28 21:36 编辑 [/i]]

愚见

从频度上说。第一种基线通常比较频繁。可能一两周一个，也可能一两天一个。第二种基线，每个文档可能只有一个，也可能后来有修改，有又几个。第三种基线，数量有限的几个，通常是项目起始时就计划好了。


看了你的文章很是赞同。有些小问题请教下：

1、基线的频度如何确定？

    这个也许会和每个公司基线发布的制度不同而变得麻烦。按照CMMI的标准，应该有个CCB单位，基线的发布一般要求通过CCB的审批通过，当然CCB考虑的范围就很大，有基线的专业性，还有市场等等原因。所以CCB的成本应该是很高的。
    这样的话，如果频繁的发布基线就会无形造成了成本的增加？？

    所以想请您指教下基线的发布要如何做？？特别是要频繁的变更基线？？这样的情况要怎么做才能让成本下降又不影响质量！！

回复 #2 shuku 的帖子

第二、三种含义的基线的频度比较好确定（准确地说，不是SCM能确定的……），我们重点看一下第一种含义的基线吧。
可以确定的是，每次开发团队对“外”（用户）发布，都需要有对应的基线。
一般来说，每次送交测试团队测试，应该有对应的基线。（当然，如果测试强调测试人员与程序员之间频繁的交互，频繁的新版本，可能不必每次做基线/Label。）
而在开发的过程中，应该定期/不定期的集成。（集成又是个话题了，这里就不展开了。）每次集成，应该有基线来反映集成的成果。如果拿不准集成的频率，可以从每周一次开始。根据情况调整。当然，如果引入了自动的每日集成/持续集成工具的话，那么频率就密得多了。可能每日一次，可能每30分钟一次……

回复 #3 流水先生 的帖子

如果测试强调测试人员与程序员之间频繁的交互，频繁的新版本，可能不必每次做基线/Label

同意，如果这样还做基线，那肯定跑累死了

把基线比喻为脚印，非常形象。

不过关于软件内部发布的频率，我同意木木的意见。不要太过频繁。否则测试工程师将无所适从，工作量大大加大。每次1次到2次的频率在实践中还是比较合适的。

回复 #5 懂你 的帖子

是啊，同意懂你的意见，一般来说，到测试团队的提交不应该太频繁，否则测试工程师将无所适从……
我见到的比较特殊的情况是，在一些敏捷开发团队里，程序员与测试工程师并肩作战，在还没有集成的情况下，就测试，甚至，在一个Task还没有完成的情况下，就测试。这样做的好处是迅速的反馈。这种情况下，有时候一个程序员一天之内可能会提供给测试工程师几十个版本……  当然，有这样的测试，也不能代替集成后“Official”的测试。“Official”的测试还是要走规范步骤的。

回复 #6 流水先生 的帖子

我公司以前没有做到这点，等到产品Codeing全部完成了集成了，在去测试，中间出现了很多的Bug，开发人员在去解决每一个Bug，这样就出来了很多的版本，开发工程师与测试工程师的工作量也加大了，有时一个产品就这样也费了，没有人在去使用管理了，后来我公司改变了存在的问题，在开发中程序员与测试工程师并肩作战，在还没有集成的情况下，就测试，甚至，在一个Task还没有完成的情况下，就测试。这样就迅速的反馈出了存在的问题，解决的也很快，后来公司就按这个规范步骤进行了。

写的很好阿，我现在的公司还是写完代码再测试，浪费时间

非常受教，谢谢！
现在公司正在进行cmmi评估，但在配置管理方面仍然存在很多的问题，虽然感觉很简单，但如果让大家都变成自己的工作习惯还是存在一定的问题，特别是在基线标识上，现在用的是Tcvs，不是很理想。

流水先生的文章很好！

我说说我们这边是怎么管理基线的。应该可以分为三种情况。

1、对于需求和设计，基本上是等评审通过之后，就会打上基线，一般这个基线就各自一条。如果项目有大的变更，需要ccb评审通过后，才能对原需求和设计的基线进行变更。

2、也就是流水先生说的 第三种，这个在项目策划的时候，就已经策划ok，也就是项目的里程碑。SCM严格按照计划执行，每个里程碑必须make baseline。并执行配置审计。

3、也就是 流水先生说的第一种，这样的基线是随着项目的进行，make的频率也是不一样的。 每个里程碑之间如果时间比较长的话，比如1个月，这时需要策划几个控制点，这几个控制点需要用基线来管理。如果项目到达coding的关键时期，我们需要每日集成，进行每日构建，这时需要每天都要make baseline。

  要是公司的配置管理作的比较不好的话，那么我认为到项目最后，版本能管理的明明白白，就算你这个cm没有白做。

  如果自认为公司的配置管理还过的去，那么我们就要对自己的要求高一点。除了版本要清晰，还要保证一致性和可追溯性，并且实现并行开发，最后能达到缩短项目工期，节省成本的效果。hoho 我觉得要是做到这点 确实有点不容易～ ，我也正在努力中～

回复

::em61::
我是初学者，看了这个基线的精彩论述，受益匪浅啊。能不能再说说里程碑呢？

开发过程中可以按照项目的进度来估算一下大概分几个版本由开发人员提交给测试人员，然后定好时间统一搜集代码进行测试，开发与测试同步。
当然前提是各个功能模块相对比较独立没有很强的关联性，如果功能关联性太强还真的没想好怎么做呢

我觉得基线的频度是不能固定的，项目的性质和规模应该对它有较大的影响，不过我在这方面没啥经验，呵

受益匪浅，也就是说第二、三种基线是可以事先定义和计划的，第一种是无法事先计划的，那么在配置管理计划中要求基线定义和计划，是不是只要包含后2类基线就可以了呢？

个人觉得基线的频度是不能固定的，因为每个公司的情况也不太一样。或者说各个项目的复杂程度也有很大的不同！！！项目的性质和规模应该对它有较大的影响吧！！

我以前的公司到了CT阶段就是频繁提交。。。。。。快搞死我了

基线：配置项在某一特定的时间通过正式评审而达到某一状态。代码或者说版本可以作为一个配置项。评审--主要是为保证质量，达到某一状态，而这个状态要有一定意义，起到里程碑的作用。频率，根据需要而定，如在上一基线的基础上增加了某个特性功能啥的，那就再建立一个基线。建立基线主要是为了保证后续的活动（开发等）提供保证，可以回溯到历史记录中的某一稳定的状态。同时，基线要保证一致性、完整性、可回溯性。

谢谢楼主的文章看了后受益匪浅

感谢楼主，文章相当精彩。。。

记得IEEE对基线的定义好像是“已经正式通过复审和批准的某规约和产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”
流水先生给我们以明白的方式解释了基线的含义；
脚印的说法，
很棒！
:em15 一个。。