使用者討論:52life
新增話題Bold text「基線」是一個很常見的術語，在配置管理和項目管理裡面都能看到，而且還有很多衍生的術語，例如基線提升、基線化、基線審計，等等等 等。
我個人以前對微軟的那套開發流程（就是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,包括可執行命令，文檔手冊，庫文件。。。