“基线”是一个很常见的术语,在配置管理和项目管理里面都能看到,而且还有很多衍生的术语,例如基线提升、基线化、基线审计,等等等等。 我个人以前对微软的那套开发流程(就是product cycle model)以及PSP、TSP了解比较多一些,这些流程里面对“基线”的概念提的不多。但接触RUP、MSF以及项目管理以后,看到到处都有baseline,就觉得迷惑了。
经过我自己的理解,以及和几个同事的讨论,现在我觉得我们通常看到的“基线”这个术语有两个意思:
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,包括可执行命令,文档手册,库文件。。。
------------------------------------------------引用自wangyou
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/shengyan/articles/540236.aspx