jasmine214--love

1) 基線：

代表多個(gè)源代碼文件的一組版本。
比如有三個(gè)文件，aaa.c、bbb.c和ccc.h。可以對(duì)這三個(gè)文件做一個(gè)基線，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一個(gè)基線。換
句話說(shuō)，通常在vss和cvs里面做label，就是在做基線。

2) 基線提升：

一個(gè)文檔如果經(jīng)過(guò)討論被通過(guò)了，被固定了，就可以說(shuō)這個(gè)文檔被“基線化”了，然后所有人就可以在這個(gè)“基線”的基礎(chǔ)上工作。

當(dāng)然，文檔不可能一成不變，所以當(dāng)對(duì)文檔的修改仍然會(huì)不斷進(jìn)行，但這種修改并不會(huì)隨時(shí)隨地的添加到被“基線化”了的文檔中去。因?yàn)榧热皇?/span>“基線”，就不能隨便動(dòng)。

但是到了一定時(shí)候，修改積累到一定程度，就需要把很多修改合并到原來(lái)的文檔中去了，并生成一個(gè)新版本的文檔作為團(tuán)隊(duì)中所有的人的參考標(biāo)準(zhǔn)，并把老的版本淘汰掉。這就叫做“基線提升”。

4）發(fā)行基線
你會(huì)對(duì)你要發(fā)行的代碼，文檔版本進(jìn)行label, 比如Release2.2,
這樣，你可以隨時(shí)取出此版本作build，進(jìn)行測(cè)試，發(fā)布。

5）產(chǎn)品基線
當(dāng)發(fā)布時(shí)，你會(huì)對(duì)產(chǎn)品中所有的配置項(xiàng)進(jìn)行label,包括可執(zhí)行命令，文檔手冊(cè)，庫(kù)文件。。。

8) 基線(Baseline)說(shuō)起. 基線是軟件文檔或源碼(或其它產(chǎn)出物)的一個(gè)穩(wěn)定版本,它是進(jìn)一步開發(fā)的基礎(chǔ).所以,當(dāng)基線形成后,項(xiàng)目負(fù)責(zé)SCM的人需要通知相關(guān)人員基線已經(jīng)形成,并 且哪兒可以找到這基線了的版本.這個(gè)過(guò)程可被認(rèn)為內(nèi)部的發(fā)布.至于對(duì)外的正式發(fā)布,更是應(yīng)當(dāng)從基線了的版本中發(fā)布.

      基線是項(xiàng)目?jī)?chǔ)存庫(kù)中每個(gè)工件版本在特定時(shí)期的一個(gè)“快照”。它提供一個(gè)正式標(biāo)準(zhǔn)，隨后的工作基于此標(biāo)準(zhǔn)，并且只有經(jīng)過(guò)授權(quán)后才能變更這個(gè)標(biāo)準(zhǔn)。建立一個(gè)初始基線后，以后每次對(duì)其進(jìn)行的變更都將記錄為一個(gè)差值，直到建成下一個(gè)基線。

      參與項(xiàng)目的開發(fā)人員將基線所代表的各版本的目錄和文件填入他們的工作區(qū)。隨著工作的進(jìn)展，基線將合并自從上次建立基線以來(lái)開發(fā)人員已經(jīng)交付的工作。變更 一旦并入基線，開發(fā)人員就采用新的基線，以與項(xiàng)目中的變更保持同步。調(diào)整基線將把集成工作區(qū)中的文件并入開發(fā)工作區(qū)。

      建立基線的三大原因是：重現(xiàn)性、可追蹤性和報(bào)告。

      重現(xiàn)性是指及時(shí)返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項(xiàng)目中的早些時(shí)候重新生成開發(fā)環(huán)境的能力。可追蹤性建立項(xiàng)目工件之間的前后繼承關(guān)系。 其目的在于確保設(shè)計(jì)滿足要求、代碼實(shí)施設(shè)計(jì)以及用正確代碼編譯可執(zhí)行文件。報(bào)告來(lái)源于一個(gè)基線內(nèi)容同另一個(gè)基線內(nèi)容的比較。基線比較有助于調(diào)試并生成發(fā)布 說(shuō)明。

      建立基線后，需要標(biāo)注所有組成構(gòu)件和基線，以便能夠?qū)ζ溥M(jìn)行識(shí)別和重新建立。

      建立基線有以下幾個(gè)優(yōu)點(diǎn)：

      基線為開發(fā)工件提供了一個(gè)定點(diǎn)和快照。
      新項(xiàng)目可以從基線提供的定點(diǎn)之中建立。作為一個(gè)單獨(dú)分支，新項(xiàng)目將與隨后對(duì)原始項(xiàng)目（在主要分支上）所進(jìn)行的變更進(jìn)行隔離。
      各開發(fā)人員可以將建有基線的構(gòu)件作為他在隔離的私有工作區(qū)中進(jìn)行更新的基礎(chǔ)。
      當(dāng)認(rèn)為更新不穩(wěn)定或不可信時(shí)，基線為團(tuán)隊(duì)提供一種取消變更的方法。
      您可以利用基線重新建立基于某個(gè)特定發(fā)布版本的配置，這樣也可以重現(xiàn)已報(bào)告的錯(cuò)誤。

      使用
      定期建立基線以確保各開發(fā)人員的工作保持同步。但是，在項(xiàng)目過(guò)程中，應(yīng)該在每次迭代結(jié)束點(diǎn)（次要里程碑），以及與生命周期各階段結(jié)束點(diǎn)相關(guān)聯(lián)的主要里程碑處定期建立基線：
      生命周期目標(biāo)里程碑（先啟階段）
      生命周期構(gòu)架里程碑（精化階段）
      初始操作性能里程碑（構(gòu)建階段）
      產(chǎn)品發(fā)布里程碑（產(chǎn)品化階段）

   區(qū)別對(duì)待缺陷和新增功能

通過(guò)進(jìn)一步了解我們發(fā)現(xiàn)緊急的變更一般是指影響系統(tǒng)正常使用的軟件缺陷，這些缺陷需要及時(shí)的修 復(fù)；而新增功能請(qǐng)求一般不是那么緊急的，允許開發(fā)團(tuán)隊(duì)有一段時(shí)間來(lái)開發(fā)實(shí)現(xiàn)。但開發(fā)人員目前是把所有緊急和非緊急的變更請(qǐng)求混雜在一起實(shí)現(xiàn)的，往往是一個(gè) 緊急的缺陷已經(jīng)修復(fù)，但另外一個(gè)正在開發(fā)中的新增功能也修改了同一組文件版本，造成兩者之間的版本依賴，從而導(dǎo)致緊急的缺陷修復(fù)不能按時(shí)提交。

我們建議把缺陷的修復(fù)工作和新增功能的開發(fā)工作區(qū)分開來(lái)，這就涉及到多個(gè)版本的并行開發(fā)，開發(fā)團(tuán)隊(duì)主要面臨以下三個(gè)版本的開發(fā)：

Ø        v1.0中的缺陷修復(fù)

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

Ø        下一個(gè)版本v2.0

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

發(fā)布版本構(gòu)建(build)而不是源代碼

這樣缺陷修復(fù)和新增功能開發(fā)相互獨(dú)立，保證緊急的缺陷修復(fù)不會(huì)受到新增功能的影響。

   版本發(fā)布管理

對(duì)于所發(fā)布的構(gòu)建版本，我們也需要進(jìn)行有序的管理，可以用版本號(hào)來(lái)唯一標(biāo)識(shí)每一個(gè)發(fā)布版本。一 般可以把用于開發(fā)團(tuán)隊(duì)內(nèi)部系統(tǒng)測(cè)試的稱之為內(nèi)部發(fā)布版本，把提交給客戶的稱之為外部發(fā)布版本，這兩種軟件發(fā)布版本都要統(tǒng)一編號(hào)管理。在我們的例子中，內(nèi)部 發(fā)布版本可以簡(jiǎn)單地用構(gòu)建號(hào)來(lái)表示，如：

v1.0_build_008      表示版本v1.0開發(fā)過(guò)程中生成的第8次構(gòu)建外部發(fā)布版本可以由版本號(hào)和發(fā)布號(hào)組合而成，如：

v1.0_rel01          表示版本v1.0的第一個(gè)外部發(fā)布版本

對(duì)于v1.0中的缺陷修復(fù)，我們可以通過(guò)補(bǔ)丁的方式來(lái)發(fā)布，一個(gè)補(bǔ)丁中可以包含有多個(gè)缺陷修復(fù)，被修復(fù)的缺陷需要在補(bǔ)丁的發(fā)布說(shuō)明(Release Notes)中寫明，補(bǔ)丁名稱可以由版本號(hào)、發(fā)布號(hào)和補(bǔ)丁號(hào)組合而成，如：

v1.0_rel01_p001     表示針對(duì)發(fā)布版本v1.0_rel01的第001號(hào)補(bǔ)丁

對(duì)于v1.0中新增功能，我們需要制定一個(gè)發(fā)布計(jì)劃，根據(jù)客戶新增功能請(qǐng)求的緊急程度來(lái)分期分批實(shí)現(xiàn)，一次發(fā)布中可以包含多個(gè)新增功能，并且包括所有已改正的軟件缺陷，這些改動(dòng)都必須在發(fā)布說(shuō)明中寫明，發(fā)布版本號(hào)可以在前一個(gè)發(fā)布版本的基礎(chǔ)上遞增，如：

v1.1_rel02          表示版本v1.1的第二個(gè)外部發(fā)布版本

對(duì)于下一個(gè)版本v2.0的開發(fā)，則與版本v1.0開發(fā)的發(fā)布管理完全一致，如：

v2.0_build_002      表示版本v2.0開發(fā)過(guò)程中生成的第2次構(gòu)建

在版本發(fā)布管理的流程中，發(fā)布版本的安裝應(yīng)該由專門的角色負(fù)責(zé)，可以是配置管理員或者是集成員(integrator)；開發(fā)人員被禁止向各平臺(tái)（測(cè)試平臺(tái)、準(zhǔn)生產(chǎn)環(huán)境、生產(chǎn)系統(tǒng)）上安裝任何軟件，并且各平臺(tái)上所安裝軟件的版本號(hào).0.0 Notes 11都應(yīng)該有詳細(xì)的記錄。當(dāng)軟件缺陷被發(fā)現(xiàn)時(shí)，我們就可以明確知道問(wèn)題究竟是出在哪一個(gè)版本。

內(nèi)部發(fā)布版本只會(huì)被安裝到測(cè)試平臺(tái)上，經(jīng)過(guò) “開發(fā) à 構(gòu)建 à 測(cè)試 à 發(fā)現(xiàn)缺陷à 修改代碼” 的多次循環(huán)之后，內(nèi)部發(fā)布版本的質(zhì)量趨于穩(wěn)定，開發(fā)團(tuán)隊(duì)才會(huì)決定做一個(gè)外部發(fā)布版本。

外部發(fā)布版本被安裝到準(zhǔn)生產(chǎn)環(huán)境上，并且只有通過(guò)用戶驗(yàn)收測(cè)試，它才可以被安裝到生產(chǎn)系統(tǒng)上 去。如果該版本沒(méi)有通過(guò)用戶驗(yàn)收測(cè)試，那么開發(fā)團(tuán)隊(duì)需要提供相應(yīng)的補(bǔ)丁來(lái)解決用戶驗(yàn)收中發(fā)現(xiàn)的問(wèn)題，直到通過(guò)用戶驗(yàn)收后再將該發(fā)布版本及其所有的累積補(bǔ)丁 全部安裝到生產(chǎn)系統(tǒng)上去。有些情況下，最終通過(guò)驗(yàn)收測(cè)試的也可能是下一個(gè)發(fā)布版本，所以生產(chǎn)系統(tǒng)上安裝的發(fā)布版本前后之間不一定是連續(xù)的，中間可能跳過(guò)一 些質(zhì)量不夠成熟的版本。

同樣的，只有通過(guò)用戶驗(yàn)收測(cè)試的補(bǔ)丁才會(huì)被最終安裝到生產(chǎn)系統(tǒng)上去。緊急的補(bǔ)丁經(jīng)過(guò)用戶驗(yàn)收測(cè)試之后會(huì)馬上安裝到生產(chǎn)系統(tǒng)上，不緊急的補(bǔ)丁可以累積幾個(gè)以后批量安裝上去。