某一開發(fā)團(tuán)隊(duì)為其客戶開發(fā)業(yè)務(wù)軟件，系統(tǒng)上線之后存在著很多的業(yè)務(wù)需求變更，同時(shí)也有很多業(yè)務(wù)部門在使用過程中所發(fā)現(xiàn)的軟件缺陷，我們把需求變更和軟件缺陷統(tǒng)稱為變更。開發(fā)團(tuán)隊(duì)需要迅速響應(yīng)客戶所提出變更請(qǐng)求，把相應(yīng)的軟件版本修復(fù)及時(shí)地安裝到生產(chǎn)系統(tǒng)上去。
為了保證產(chǎn)品質(zhì)量，該開發(fā)團(tuán)隊(duì)建立了以下的軟件發(fā)布流程：
這四個(gè)環(huán)節(jié)分別對(duì)應(yīng)以下四種環(huán)境：
開發(fā)環(huán)境：開發(fā)實(shí)現(xiàn)客戶的變更請(qǐng)求
測(cè)試平臺(tái)：開發(fā)團(tuán)隊(duì)把軟件發(fā)布給客戶之前做內(nèi)部系統(tǒng)測(cè)試
準(zhǔn)生產(chǎn)環(huán)境：客戶把軟件發(fā)布到生產(chǎn)系統(tǒng)之前做驗(yàn)收測(cè)試
生產(chǎn)系統(tǒng)：最終的生產(chǎn)系統(tǒng)
當(dāng)開發(fā)團(tuán)隊(duì)將變更實(shí)現(xiàn)提交用戶驗(yàn)收測(cè)試時(shí)，凡是沒有通過驗(yàn)收測(cè)試的變更將被拒絕，只有通過驗(yàn)收測(cè)試的變更才會(huì)被部署到生產(chǎn)系統(tǒng)上去。整個(gè)流程如下圖所示，假設(shè)開發(fā)團(tuán)隊(duì)總共實(shí)現(xiàn)了3個(gè)變更，其中變更1和變更2通過了系統(tǒng)測(cè)試被提交用戶驗(yàn)收測(cè)試，但只有變更1通過了用戶驗(yàn)收測(cè)試，最終只有變更1被部署到生產(chǎn)系統(tǒng)上。
為了支持這種工作流程，該團(tuán)隊(duì)分別在配置管理系統(tǒng)中管理了四種源代碼版本：
凡是通過每一個(gè)環(huán)節(jié)的變更所對(duì)應(yīng)的源代碼版本，將被復(fù)制到下一個(gè)環(huán)節(jié)的版本基線中去?？瓷先ミ@一流程非常合理，不是嗎？
讓我們來看這種流程的兩個(gè)應(yīng)用案例。
在下面的例子中，文件f1、f2在修改之前的版本都是1，在實(shí)現(xiàn)了變更1、變更2后，它們的版本都變?yōu)榱税姹?，表示為f1(v2)、f2(v2)。在整個(gè)的測(cè)試過程中，前面三個(gè)環(huán)境上測(cè)試的代碼版本始終是文件f1和f2的版本2，但是最后變更1沒有通過驗(yàn)收測(cè)試而變更2通過了，那么最終被部署到生產(chǎn)系統(tǒng)上去的版本將是：
f1(v1，這是f1原來在生產(chǎn)系統(tǒng)上的版本)
f2(v2，其中已包含了變更2所對(duì)應(yīng)的版本2)
但f1(v1)應(yīng)該是跟f1(v1，變更1修改以前的版本)相匹配的版本組合，跟f2(v2)相匹配的版本組合應(yīng)該是f1(v2)，由此可能發(fā)生的結(jié)果是：
在生產(chǎn)系統(tǒng)上運(yùn)行的是未經(jīng)測(cè)試的版本組合!
在下面的例子中，在前面三個(gè)測(cè)試環(huán)節(jié)中，文件f2被測(cè)試的版本都是版本4。當(dāng)變更2未通過用戶驗(yàn)收測(cè)試時(shí)，文件f2最終被復(fù)制到生產(chǎn)系統(tǒng)上的版本為3，這個(gè)版本是未經(jīng)測(cè)試的。
結(jié)果令人難以置信：
在生產(chǎn)系統(tǒng)上運(yùn)行的是未經(jīng)測(cè)試的版本?!
任何一個(gè)軟件系統(tǒng)，它的所有代碼應(yīng)該被作為一個(gè)整體來進(jìn)行交付，而不是象上述例子中那樣只交付部分的代碼（變更相關(guān)的代碼）,這是造成質(zhì)量陷阱的根本原因。一個(gè)看上去合理的流程存在本質(zhì)的缺陷。
為了避免以上所述的這些質(zhì)量陷阱，我們應(yīng)該改進(jìn)現(xiàn)有的配置管理流程。
造成以上質(zhì)量隱患的根本原因是系統(tǒng)代碼沒有被作為一個(gè)整體來處理，并且在發(fā)布過程中我們發(fā)布的是源代碼，正確的流程（也是業(yè)界較為通行的做法）應(yīng)該發(fā)布構(gòu)建后的目標(biāo)碼而非源代碼。我們可以建立一個(gè)閉環(huán)的質(zhì)量保證流程（如下圖所示）來批量地進(jìn)行軟件發(fā)布。
其中系統(tǒng)測(cè)試過程中發(fā)現(xiàn)的缺陷應(yīng)該被開發(fā)人員及時(shí)改正，然后再做構(gòu)建，再測(cè)試，直到達(dá)到一個(gè)比較穩(wěn)定的版本才會(huì)發(fā)布到驗(yàn)收測(cè)試環(huán)節(jié)。同樣的，驗(yàn)收測(cè)試中發(fā)現(xiàn)的問題也會(huì)回到開發(fā)環(huán)節(jié)進(jìn)行修復(fù)。這應(yīng)該是一個(gè)多次循環(huán)的過程，不斷地發(fā)現(xiàn)錯(cuò)誤，然后改正，再測(cè)試。這個(gè)循環(huán)到什么時(shí)候結(jié)束呢？這個(gè)取決于各個(gè)軟件項(xiàng)目的實(shí)際情況：
◆ 最理想的情況當(dāng)然是到所有的缺陷都被改正為止，但是所花的時(shí)間比較長，可能趕不上項(xiàng)目的進(jìn)度要求，現(xiàn)實(shí)工作不大可能做到這一點(diǎn)。
◆ 折衷的情況是所有嚴(yán)重的缺陷（即那些影響系統(tǒng)使用的的缺陷）都必須被改正，但允許有一些已發(fā)現(xiàn)的缺陷遺留到后面再去解決,前提是所遺留的缺陷不會(huì)影響其他變更的實(shí)現(xiàn)。大家平時(shí)在一些商用軟件的新版本中經(jīng)?？梢砸姷?strong>發(fā)布說明(Release Notes)中所列的已知缺陷(Known Defects)就是屬于這種情況。
我們向開發(fā)團(tuán)隊(duì)提出這個(gè)建議后，馬上遭到項(xiàng)目經(jīng)理的反對(duì)：“客戶有些緊急的變更需要馬上實(shí)現(xiàn)并交付生產(chǎn)運(yùn)營，幾乎沒有時(shí)間來走這樣完整的閉環(huán)流程?！?/p>
通過進(jìn)一步了解我們發(fā)現(xiàn)：
緊急的變更一般是指影響系統(tǒng)正常使用的軟件缺陷，這些缺陷需要及時(shí)的修復(fù)；而新增功能請(qǐng)求一般不是那么緊急的，允許開發(fā)團(tuán)隊(duì)有一段時(shí)間來開發(fā)實(shí)現(xiàn)。
但開發(fā)人員目前是把所有緊急和非緊急的變更請(qǐng)求混雜在一起實(shí)現(xiàn)的，往往是一個(gè)緊急的缺陷已經(jīng)修復(fù)，但另外一個(gè)正在開發(fā)中的新增功能也修改了同一組文件版本，造成兩者之間的版本依賴，從而導(dǎo)致緊急的缺陷修復(fù)不能按時(shí)提交。
我們建議：
把缺陷的修復(fù)工作和新增功能的開發(fā)工作區(qū)分開來。
這就涉及到多個(gè)版本的并行開發(fā)，開發(fā)團(tuán)隊(duì)主要面臨以下三個(gè)版本的開發(fā)：
◆ v1.0中的缺陷修復(fù)
◆ v1.0的新增功能版本v1.1
◆ 下一個(gè)版本v2.0
這樣缺陷修復(fù)和新增功能開發(fā)相互獨(dú)立，保證緊急的缺陷修復(fù)不會(huì)受到新增功能的影響。
這個(gè)案例中另外有一個(gè)不符合配置管理慣例的地方是，在開發(fā)、測(cè)試、驗(yàn)收、生產(chǎn)四個(gè)環(huán)節(jié)發(fā)布的都是源代碼，分別需要構(gòu)建(包括編譯)過后才能部署到相應(yīng)的運(yùn)行平臺(tái)上。
由于軟件構(gòu)建的結(jié)果很可能會(huì)受構(gòu)建平臺(tái)及相應(yīng)編譯器版本所影響，最終在生產(chǎn)系統(tǒng)上的運(yùn)行代碼(在生產(chǎn)系統(tǒng)上構(gòu)建得到)與準(zhǔn)生產(chǎn)環(huán)境上的運(yùn)行代碼(在準(zhǔn)生產(chǎn)環(huán)境上構(gòu)建得到)可能不完全一致，有可能造成質(zhì)量隱患。
比較通行的做法是所有平臺(tái)上運(yùn)行的構(gòu)建代碼應(yīng)該只在構(gòu)建服務(wù)器上生成一次，一次編譯到處運(yùn)行，這樣才能保證各個(gè)平臺(tái)上所用到的同版本運(yùn)行代碼是同一次構(gòu)建的產(chǎn)物。
構(gòu)建服務(wù)器通常就是由開發(fā)平臺(tái)兼任，但如果是發(fā)布多個(gè)不同運(yùn)行平臺(tái)的版本的話，可以有多個(gè)構(gòu)建服務(wù)器存在，如：同一個(gè)軟件既有 AIX + DB2 平臺(tái)的運(yùn)行版本，也有 HPUX + Oracle 平臺(tái)的運(yùn)行版本。
除了某些特殊的運(yùn)行環(huán)境外，如IBM主機(jī)系統(tǒng)(mainframe)上明確要求在運(yùn)行平臺(tái)上對(duì)源代碼進(jìn)行編譯構(gòu)建，一般軟件系統(tǒng)的開發(fā)都可以遵循這一個(gè)工作原則。
對(duì)于所發(fā)布的構(gòu)建版本，我們也需要進(jìn)行有序的管理，可以用版本號(hào)來唯一標(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ā)布版本可以簡單地用構(gòu)建號(hào)來表示，如：
v1.0_build_008，表示版本v1.0開發(fā)過程中生成的第8次構(gòu)建
外部發(fā)布版本可以由版本號(hào)和發(fā)布號(hào)組合而成，如：
v1.0_rel01，表示版本v1.0的第一個(gè)外部發(fā)布版本
對(duì)于v1.0中的缺陷修復(fù)，我們可以通過補(bǔ)丁的方式來發(fā)布，一個(gè)補(bǔ)丁中可以包含有多個(gè)缺陷修復(fù)，被修復(fù)的缺陷需要在補(bǔ)丁的發(fā)布說明(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)求的緊急程度來分期分批實(shí)現(xiàn)，一次發(fā)布中可以包含多個(gè)新增功能，并且包括所有已改正的軟件缺陷，這些改動(dòng)都必須在發(fā)布說明中寫明，發(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ā)過程中生成的第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)都應(yīng)該有詳細(xì)的記錄。
當(dāng)軟件缺陷被發(fā)現(xiàn)時(shí)，我們就可以明確知道問題究竟是出在哪一個(gè)版本。
內(nèi)部發(fā)布版本只會(huì)被安裝到測(cè)試平臺(tái)上，經(jīng)過 “開發(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)境上，并且只有通過用戶驗(yàn)收測(cè)試，它才可以被安裝到生產(chǎn)系統(tǒng)上去。
如果該版本沒有通過用戶驗(yàn)收測(cè)試，那么開發(fā)團(tuán)隊(duì)需要提供相應(yīng)的補(bǔ)丁來解決用戶驗(yàn)收中發(fā)現(xiàn)的問題，直到通過用戶驗(yàn)收后再將該發(fā)布版本及其所有的累積補(bǔ)丁全部安裝到生產(chǎn)系統(tǒng)上去。
有些情況下，最終通過驗(yàn)收測(cè)試的也可能是下一個(gè)發(fā)布版本，所以生產(chǎn)系統(tǒng)上安裝的發(fā)布版本前后之間不一定是連續(xù)的，中間可能跳過一些質(zhì)量不夠成熟的版本。
同樣的，只有通過用戶驗(yàn)收測(cè)試的補(bǔ)丁才會(huì)被最終安裝到生產(chǎn)系統(tǒng)上去。緊急的補(bǔ)丁經(jīng)過用戶驗(yàn)收測(cè)試之后會(huì)馬上安裝到生產(chǎn)系統(tǒng)上，不緊急的補(bǔ)丁可以累積幾個(gè)以后批量安裝上去。
配置管理工具 IBM Rational ClearCase 可以很好地支持這種并行開發(fā)模式。在 ClearCase UCM (Unified Change Management，統(tǒng)一變更管理流程)工作模式中，我們可以在版本v1.0的發(fā)布版本基線(v1.0_rel01)的基礎(chǔ)上分別創(chuàng)建針對(duì)三種版本(v1.0_bugfix, v1.1, v2.0)的開發(fā)項(xiàng)目，如下圖所示。
在 ClearCase 的管理下，這三種版本位于不同的分支上，它們的開發(fā)是獨(dú)立的，互不影響；并且版本 v1.0_bugfix 中的缺陷修復(fù)可以及時(shí)地合并到版本 v1.1 和 v2.0 中去，版本 v1.1 中的新增功能也可以在需要的時(shí)候合并到版本 v2.0 中去。（如下圖所示）
ClearCase 也為開發(fā)人員提供了方便易用的工作界面 ClearCase Explorer，開發(fā)人員可以方便地選擇任何一個(gè)版本項(xiàng)目來進(jìn)行開發(fā)工作，ClearCase Explorer 可以迅速準(zhǔn)確地準(zhǔn)備相應(yīng)的工作版本。所以這三種不同版本的開發(fā)完全可以由同一組開發(fā)人員來完成，大大提高了開發(fā)的工作效率。
在這個(gè)案例學(xué)習(xí)中我們看到配置管理流程對(duì)于保證軟件質(zhì)量起著非常重要的作用，不恰當(dāng)?shù)牧鞒炭赡軐?dǎo)致潛在的質(zhì)量缺陷，開發(fā)團(tuán)隊(duì)需要根據(jù)自身項(xiàng)目的情況來制定一個(gè)高效合理的配置管理流程。有了一個(gè)好的流程，還需要一個(gè)好的配置管理工具來簡化我們的管理工作，從而保證開發(fā)人員的工作效率和軟件質(zhì)量。
聯(lián)系客服
