/協(xié)作開發(fā)中的質(zhì)量保證技術(shù)——并行版本限制、每日構(gòu)建和交付工程書目

\o":///articles/services/view.asp?id=795&page=1#Abstract"摘要

\o":///articles/services/view.asp?id=795&page=1#Problem"問題的提出

\o":///articles/services/view.asp?id=795&page=1#CVS"并行版本限制——多人協(xié)作開發(fā)的有效保障

\o":///articles/services/view.asp?id=795&page=1#KeepSync"代碼提交和同步4

\o":///articles/services/view.asp?id=795&page=1#CommitMail"編碼過程中的溝通紐帶——commitmail

\o":///articles/services/view.asp?id=795&page=1#NightlyBuild"日常測試——每日構(gòu)建

\o":///articles/services/view.asp?id=795&page=1#BranchingAndTag"有效的版本限制——代碼分支、版本標(biāo)記

\o":///articles/services/view.asp?id=795&page=1#Freezes"特性凍結(jié)和代碼凍結(jié)

\o":///articles/services/view.asp?id=795&page=1#RELENG"交付工程

\o":///articles/services/view.asp?id=795&page=1#Conclusion"總結(jié)

\o":///articles/services/view.asp?id=795&page=1#References"參考文獻(xiàn)

\o":///articles/services/view.asp?id=795&page=1#Author"作者簡介摘要本文以cvs為例，介紹了軟件工程中，編碼過程中對于版本限制的運(yùn)用的一些技巧。在最終部分，還介紹了軟件工程最終的“交付工程”。問題的提出編碼過程是軟件工程的重要一環(huán)。這一部分工作的好壞干脆關(guān)系到軟件產(chǎn)品的質(zhì)量。高效率的多人協(xié)作開發(fā)，依靠于團(tuán)隊精神、設(shè)計師對于軟件架構(gòu)的整體把握、好的并行版本限制技術(shù)，以及制度化的每日構(gòu)建和最終階段的交付工程。今年六月，我有幸在一家開發(fā)平安軟件的公司觀摩了他們的每日構(gòu)建和交付工程中的活動。他們對于并行版本限制、每日構(gòu)建技術(shù)嫻熟而深化的應(yīng)用給我留下了特別深刻的印象。在此，我愿和讀者一同共享我自己的學(xué)習(xí)體會，這其中的某些部分得益于在那家公司的實(shí)地觀摩，另一些則來自于我自己參與的實(shí)際軟件工程項(xiàng)目的體會。毫無疑問地，一個軟件工程項(xiàng)目最有價值的部分還是在它的設(shè)計階段。良好的設(shè)計能夠讓實(shí)現(xiàn)環(huán)節(jié)變得更有效率，從而極大地提高勞動生產(chǎn)率；而好的編碼規(guī)范，則是協(xié)同開發(fā)的重要基石。限于篇幅，對于前述兩項(xiàng)內(nèi)容本文將不會過多設(shè)計，我將著重介紹軟件工程中編碼和測試環(huán)節(jié)的一些閱歷，這些閱歷對于已經(jīng)擁有優(yōu)秀的軟件設(shè)計師和編程、測試人員，而苦于由于連調(diào)、最終測試導(dǎo)致發(fā)布頻頻延期的開發(fā)團(tuán)隊來說是特別有益的。并行版本限制——多人協(xié)作開發(fā)的有效保障設(shè)想一個有4名編程人員的小型開發(fā)團(tuán)隊(以下簡稱“TJRP開發(fā)組”)，Tom、Jason、Robert和Pat分別負(fù)責(zé)4個模塊，依據(jù)傳統(tǒng)的軟件開發(fā)模式，開發(fā)將經(jīng)驗(yàn)編程-連調(diào)-測試-發(fā)布4個階段。假如最初的設(shè)計正確，并且，四個開發(fā)人員都是Guru級的程序員而且協(xié)作默契，那么這個模式將會運(yùn)轉(zhuǎn)良好。然而缺憾的是，Pat剛剛參與工作不久，對于設(shè)計師撰寫的設(shè)計文檔的理解不夠透徹，而Robert則自作主見地對設(shè)計進(jìn)行了一些修正，更糟糕的是，項(xiàng)目組會議的時候，這些問題沒有剛好地被暴露出來，導(dǎo)致Pat和Robert代碼在設(shè)計上的“分歧”越來越大。結(jié)果，進(jìn)入連調(diào)的階段，Pat和Robert發(fā)生了激烈的爭吵，在吵得不行開交之后，項(xiàng)目經(jīng)理最終讓4個人坐到了一起來解決問題，最終，連調(diào)階段整整多花了一倍的時間。但倒霉的事情還沒有結(jié)束。Jason在測試中發(fā)覺，原本正常的代碼的行為被變更了，并且，他驚異地發(fā)覺代碼被某個“別人”改過，在翻箱倒柜地找出某份正常版本的副本之后，他又發(fā)覺，“別人”修改中的某些地方是必要的。代碼合并和重新測試使得測試階段足足花掉了原先預(yù)想3倍的時間?？蓱z的Tom運(yùn)氣更差，作為主要的代碼復(fù)審人員，他不得不閱讀全部的代碼。Robert和Pat的爭吵導(dǎo)致了大量的代碼變動，他不得不重新審核代碼，而Jason的代碼合并引發(fā)的新問題又讓他不得不分神去幫助Jason進(jìn)行調(diào)整。最終的結(jié)果是，軟件開發(fā)的成本是預(yù)期的2.4倍，發(fā)布時間也拖后了不少。我并不是在開玩笑，上面所講的是一個發(fā)生在那家平安軟件公司的真實(shí)故事。他們的技術(shù)經(jīng)理介紹，在施行了規(guī)范的開發(fā)制度，以及啟用并行版本限制系統(tǒng)之后，他們認(rèn)為開發(fā)達(dá)到了一個全新的水平。并行版本限制系統(tǒng)本身并沒有產(chǎn)生任何代碼，但由于運(yùn)用這樣的系統(tǒng)，開發(fā)的效率被大大地提高了。所謂版本限制其實(shí)并不是什么困難的概念。對于開發(fā)活動的絕大多數(shù)參和者來說，版本限制系統(tǒng)在某種意義上能夠幫助他們做好開發(fā)過程中的記錄工作，并且，通過保存文件在不同時期的版本，交付工程師和代碼復(fù)審員能夠很簡潔地縮小搜尋問題代碼的范圍，而程序員則可以通過這樣的系統(tǒng)更好地并行協(xié)作。一般來說，源代碼的版本限制系統(tǒng)能夠?qū)崿F(xiàn)以下一些最基本的功能：保存隨意一個源代碼文件的不同版本記錄修改者、修改緣由當(dāng)兩個用戶同時修改一個文件時，盡可能地自動合并修改；在不能合并時，給出提示比較不同版本之間，或和本地副本之間的差異獲得最新版本的全部源代碼供測試，并允許回退到所保存的源代碼的隨意版本創(chuàng)建代碼分支，便于軟件發(fā)布和后期維護(hù)(后面將會提到)；新的代碼可以合并到這些分支中。對不同的源代碼給出標(biāo)記，便利日后審查訪問限制：阻擋未經(jīng)授權(quán)的修改和查閱我們知道，技術(shù)不是解決一切問題的靈丹妙藥，但是誰也不會否認(rèn)大規(guī)模的機(jī)械化生產(chǎn)的效率高于人拉肩扛的手工業(yè)作坊，一旦運(yùn)用得當(dāng)，技術(shù)將極大地改善我們的工作和生活。我們可以看到，上面的功能有效地解決了TJRP開發(fā)組所面臨的絕大部分問題，例如：由于能夠同時修改代碼，并獲得對方的修改，Pat和Robert能夠有效地、盡早地進(jìn)行溝通促進(jìn)開發(fā)者之間的溝通，每一個修改都必需給出緣由，并記錄提交者測試和連調(diào)可以盡早起先，避開模塊之間的不兼容在最終階段被暴露出來而阻礙發(fā)布不同開發(fā)者的修改能夠剛好合并，并避開由于版本不一樣導(dǎo)致的沖突代碼復(fù)審可以針對某一代碼分支進(jìn)行，從而，允許一些開發(fā)者持續(xù)地開發(fā)下一個版本，而穩(wěn)定的代碼則可以交付給用戶更進(jìn)一步，以管理者的角度，還有了一些額外的好處，如：每日構(gòu)建和測試能夠讓項(xiàng)目經(jīng)理更好地把握工程的進(jìn)度誰作了多少工作，誰工作的更精彩，可以在版本限制系統(tǒng)中清晰地體現(xiàn)分工明確，通過訪問限制，可以避開不了解整個代碼體系的開發(fā)人員偶然的錯誤修改導(dǎo)致的全盤崩潰更重要地，版本限制系統(tǒng)中將保持大量的開發(fā)閱歷，這對于一個開發(fā)團(tuán)隊來說是一筆無價的財寶我們可以看到，上述改進(jìn)集中地體現(xiàn)了一個重要的思想，即：剛好溝通以預(yù)防問題的出現(xiàn)；盡早發(fā)覺、盡早解決問題；明確獎懲制度，激發(fā)開發(fā)人員的主動性。下面我們將以特別常見的版本限制系統(tǒng)——cvs[1]為例，介紹并行版本系統(tǒng)一些基本的運(yùn)用原理。代碼提交和同步——從update和commit說起每當(dāng)我們起先一個新的修改之前，首先要做的是從代碼庫中提取出一份最新的副本(通過update操作完成)；在本地修改、粗調(diào)之后，則應(yīng)盡快將代碼提交回代碼庫(通過commit操作完成)?；镜膗pdate和commit操作流程如下圖所示：

圖1.cvsupdate和commit這兩項(xiàng)操作也解決了日常開發(fā)大約80%的問題。絕大多數(shù)狀況下，這部分的工作是相當(dāng)簡潔的，除非出現(xiàn)兩個開發(fā)者同時修改同一個文件的狀況，例如，兩個開發(fā)者同時地修改了同一個文件的同一個版本，這種情形稱為沖突：圖2.cvs并行開發(fā)中的沖突可能開發(fā)者B的動作比較快，或者，修改的東西比較簡潔，于是他首先提交。在A、B從代碼庫中提取代碼時，最新版本是1.1，于是，B提交的版本被版本限制系統(tǒng)命名為1.2。但不久，A想要提交代碼，版本限制系統(tǒng)將拒絕他的提交，因?yàn)樗男薷幕诖a的1.1版，而目前的最新版本已經(jīng)是1.2了。cvs供應(yīng)了自動合并功能，允許在兩個人修改的不是同一行代碼的前提下，自動合并本地修改和最新的代碼，當(dāng)然，假如趕上兩個人同時修改同一行代碼的狀況，cvs也會特別“聰慧”地把兩個“英雄所見略同”的地方合并。但假如兩個人恰好都修改了同一行代碼，而且改的不一樣怎么辦？cvs會告知后一個提交的開發(fā)者發(fā)生了這樣的狀況，并且要求他解決問題。代碼中存在的差異將以<<<和>>>標(biāo)記出來，以便利進(jìn)行修改。簡潔說來，當(dāng)發(fā)生沖突時，我們通常約定由后一個提交者解決沖突——當(dāng)然，他可以選擇忽視這些沖突，但這些操作都會被記錄，更何況，統(tǒng)計顯示，同時將一行代碼修改為兩種不同的樣子這樣的狀況在實(shí)際開發(fā)中很少出現(xiàn)。于是，修改流程接著，如下圖：圖3.開發(fā)者A解決沖突，并提交極端狀況下，可能出現(xiàn)多個開發(fā)者同時修改同一個文件的問題。這一問題基本上可以依據(jù)上述的方法解決。當(dāng)然，為了避開發(fā)生這樣的情形，在設(shè)計的時候就應(yīng)當(dāng)讓每個人工作的代碼盡可能地不重疊。下面是特別基本的cvsupdate/commit操作規(guī)范：

簡潔的cvs操作約定修改文件之前首先update。這意味著修改時的版本盡可能新，一旦發(fā)生沖突，解決它的工作量會比較小。剛好commit。本地代碼和代碼庫中的代碼差異越小，別人合并的難度也就越小(他們有比較大的概率能夠拿到新的版本)將不同的功能單元修改分開commit。一方面，這樣做能夠盡早地commit，削減別人合并的難度；另一方面，由于cvs供應(yīng)了回退到從前版本的實(shí)力，一旦由于某項(xiàng)功能修改造成問題，也很簡潔將那次修改的內(nèi)容，而不是整個修改回退到正常的代碼。同一功能涉及的全部代碼一次commit。不希望將涉及同一功能修改的代碼分開commit，因?yàn)檫@會給日后的追蹤帶來麻煩。先調(diào)試后提交。這將削減別人不會因?yàn)橥搅酥虚g結(jié)果引發(fā)問題，甚至發(fā)生提交沖突的可能。寫清commitlog(提交日志)。cvs中允許保存commitlog，在這里可以寫為什么進(jìn)行代碼的修改，以及進(jìn)行了什么樣的修改，清晰的commitlog能夠幫助其他開發(fā)者在不細(xì)致閱讀代碼的狀況下了解修改的內(nèi)容，從而極大地提高開發(fā)效率；另一方面，這些日志對于開發(fā)者自己，以及整個開發(fā)團(tuán)隊，都是特別珍貴的財寶。同步代碼(update)和提交代碼(commit)占到了cvs日常操作的80%以上。從上面的介紹我們可以看出，僅僅依靠這兩項(xiàng)特別簡潔的功能，cvs就能極大地改善開發(fā)流程，并提高軟件工程的可控性。簡潔地說：全體開發(fā)者運(yùn)用同一個中心代碼庫，從而消退了由于來回復(fù)制文件導(dǎo)致的不一樣。發(fā)生沖突時，后提交的開發(fā)者必需解決它。這名開發(fā)者能夠知道是誰引入了沖突，他可以自己解決沖突，也可以和引入沖突的開發(fā)者商議如何解決沖突。測試可以貫穿編碼過程的始終，任何時候引入的新問題都能夠被剛好追蹤、快速定位，從而更有效地解決。由于存在中心代碼庫，代碼審核人員和每日構(gòu)建人員能夠剛好地了解代碼是否存在問題，并幫助項(xiàng)目經(jīng)理保證開發(fā)進(jìn)度。有助于幫助開發(fā)人員養(yǎng)成嚴(yán)謹(jǐn)?shù)墓ぷ髁?xí)慣——規(guī)則要求他們將盡可能地提交正確的代碼，并且每個修改必需寫commitlog進(jìn)行說明。有助于建立更公允的工作質(zhì)量評估機(jī)制。cvs能夠記錄每個人完成的實(shí)際工作量，包括他們因?yàn)樾拚龁栴}等等所作的勞動，以及他們完成代碼的質(zhì)量狀況。這樣，管理者能夠?yàn)閮?yōu)秀的開發(fā)人員供應(yīng)更好的工作機(jī)會、酬勞，等等，這對于鼓舞整個團(tuán)隊的士氣、提高開發(fā)人員的工作主動性都是特別有益的。促進(jìn)開發(fā)人員之間的溝通。盡管cvs本身無法代替溝通，但commitlog，以及cvs系統(tǒng)獲得隨意版本之間差異的實(shí)力，能夠幫助開發(fā)人員了解對方的想法，并促進(jìn)他們共同提高。降低程序開發(fā)人員的門檻。由于供應(yīng)了很多特別便利的協(xié)同開發(fā)手段，運(yùn)用cvs能夠削減協(xié)同開發(fā)所須要的磨合期，同時，不同層次的開發(fā)者之間由于能夠進(jìn)行常常性的溝通，從而把編碼過程從技能型工作向嫻熟性工作又推動了一步。這意味著高層次的開發(fā)人員能夠去進(jìn)行更能發(fā)揮他們特長的工作，而新手則可以很快地融入到日常的開發(fā)活動中來，從而提高勞動生產(chǎn)率，降低開發(fā)成本。編碼過程中的溝通紐帶——commitmailcvs是一項(xiàng)開放性很強(qiáng)的工具，它可以被特別簡潔地訂制。一般來說，cvs服務(wù)器會架設(shè)在一臺Unix主機(jī)上(我們舉薦運(yùn)用FreeBSD)，通過運(yùn)用腳本語言(例如，Perl)，cvs能夠完成一些額外的功能。commitmail是commitlog在郵件系統(tǒng)上的延長。下面是一封典型的commitmail，它來自FreeBSD開發(fā)團(tuán)隊：phk2003/10/2123:32:20PDT

FreeBSDsrcrepository

Modifiedfiles:

sys/geomgeom_io.c

Log:

Forgottencommit:Ifaproviderhaszerosectorsize,itisan

indicationoflackofmedia.

Trippedup:peter

RevisionChangesPath

1.50

+3-6

src/sys/geom/geom_io.c我們看到，上面的這封commitmail中提到了開發(fā)者(phk)、提交時間(太平洋時間2003年10月21日23:32:20)、涉及的代碼庫名字(FreeBSDsrcrepository)、修改過的文件(sys/geom的geom_io.c)以及commitlog。最終，commitlog還提到了提交后文件的最新版本(1.50)，修改規(guī)模(+3-6)以及代碼的實(shí)際路徑。實(shí)現(xiàn)上面的功能并不困難，事實(shí)上，您只須要下載一套經(jīng)過定制的FreeBSDcvs代碼庫(壓縮包不超過40KB)，并作少量的調(diào)整，就能夠干脆運(yùn)用這些功能(我們將在不久以后發(fā)布這些內(nèi)容)。進(jìn)行這些訂制甚至不須要基本的Perl和C/C++常識就能夠完成——當(dāng)然，我想這樣的常識對于軟件開發(fā)人員來說，并不算是很高的要求。commitmail可以通過郵件列表發(fā)給全體開發(fā)者。很多大的軟件公司，以及開放源代碼團(tuán)體，都采納這樣的方式來協(xié)調(diào)開發(fā)活動。日常測試——堅持每日構(gòu)建傳統(tǒng)的軟件工程中，測試發(fā)生在連調(diào)之后。這么做的理論依據(jù)是，測試依靠于一份一樣的、至少能夠正常編譯并啟動的代碼。而這個條件在連調(diào)之前是無法滿意的。然而在有了版本限制系統(tǒng)(如，cvs)之后，連調(diào)變成了開發(fā)中的日常行為。代碼幾乎在每一時刻都處于高度的一樣狀態(tài)，甚至在很多時候，代碼會處于可用狀態(tài)，從而為測試創(chuàng)建特別有利的條件。很多大型開發(fā)團(tuán)隊會運(yùn)用一臺甚至多臺被稱作TinderBox的機(jī)器來完成每日構(gòu)建和測試。簡潔的每日構(gòu)建流程如下：測試工程師，或代碼復(fù)審員從代碼庫中提取一份代碼的快照相關(guān)人員在TinderBox上進(jìn)行編譯編譯的任何錯誤被追蹤，測試工程師或代碼復(fù)審員將回退代碼到上一次能夠勝利編譯的點(diǎn)，并和此后進(jìn)行代碼提交的其他開發(fā)者進(jìn)行聯(lián)系，解決問題測試工程師對于代碼進(jìn)行測試其中，第一、二步是可以通過腳本定時、自動完成的，不須要人工干預(yù)。第三步中的編譯錯誤在軟件開發(fā)中間或會發(fā)生(這可能來自于沖突合并時引發(fā)的問題，但由于開發(fā)人員的本地測試，這種文體不會是常常性的)，習(xí)慣上，這些錯誤會由代碼復(fù)審員去追蹤和處理，并交給相關(guān)的開發(fā)人員解決。測試工程師可以將編譯好的版本交付給一個測試組，甚至用戶去進(jìn)行測試。測試工程師可能隨時發(fā)布軟件的“快照”版本。事實(shí)上在很多大公司中，每日構(gòu)建是特別“習(xí)以為?！钡氖虑?。我們看到的InternetExplorer版本，如6.0.2600或者類似6.0Build2600中的2600的意思就是這份代碼之前已經(jīng)經(jīng)驗(yàn)了2600次每日構(gòu)建操作(當(dāng)然，中間確定進(jìn)行過不少修改，而且，也不解除這個2600是有意湊整得到的，但總之，他們進(jìn)行了相當(dāng)多的日常構(gòu)建工作)。在軟件開發(fā)的后期，由于發(fā)布的燃眉之急，每日構(gòu)建很可能會演化為持續(xù)構(gòu)建，即，每次commit觸發(fā)一次構(gòu)建操作。全部問題馬上得到反饋。為了支持每日構(gòu)建或持續(xù)構(gòu)建，比較志向的方法是采納Makefile完成構(gòu)建操作。對于Unix系統(tǒng)，make工具通常是pmake(BSDMake)或gmake(GNUMake)；對于VisualC++，則是nmake。大的開發(fā)團(tuán)體通常運(yùn)用一組腳原來完成全部的make操作，而對于中小型項(xiàng)目，手工地運(yùn)用類似VC++這樣的IDE本身的構(gòu)建功能也是可以接受的?；镜拿咳諛?gòu)建規(guī)范如下：

基本的每日構(gòu)建和測試留意事項(xiàng)避開在存在開發(fā)人員大規(guī)模地進(jìn)行commit時提取快照。此時提取的中間結(jié)果很可能有問題，并導(dǎo)致每日構(gòu)建從頭做起。通常，測試工程師和代碼復(fù)審員在多數(shù)開發(fā)人員下班的時候起先每日構(gòu)建，因此，每日構(gòu)建有時也被稱作每晚構(gòu)建(NightlyBuild)。標(biāo)記(tag)每日構(gòu)建中能夠正確編譯的版本。這將削減其次天每日構(gòu)建中的麻煩。剛好通知造成問題的開發(fā)人員，即，所涉及代碼的提交者。某些公司甚至要求員工開著手機(jī)和尋呼機(jī)，以保證工期。作為commitmail的有效補(bǔ)充，很多項(xiàng)目開發(fā)組會建立郵件列表來傳遞一些相關(guān)的信息。測試日報通常會發(fā)給整個開發(fā)團(tuán)隊的參與人員，此外，保留一個出現(xiàn)過的問題記錄，對于測試環(huán)節(jié)也會有相當(dāng)大的好處——這些問題在隨后被反復(fù)測試，以保證最終的RELEASE不出現(xiàn)這些問題。每日構(gòu)建并不是可有可無的工作，作為日常測試的重要手段，每日構(gòu)建能夠有效地幫助管理者了解工程進(jìn)度，幫助開發(fā)者盡早發(fā)覺問題，同時，也會促進(jìn)開發(fā)組中的溝通。有效的版本限制——版本標(biāo)記、代碼分支三個文件的“最新版本”分別是1.5,1.3,1.4，但最新版本不確定是我們須要的。在這種狀況下，版本限制系統(tǒng)供應(yīng)了一個特別重要的機(jī)制——版本標(biāo)記。例如，我們目前已經(jīng)確認(rèn)三個文件的1.4,1.3,1.4組合在一起能夠正常運(yùn)行，于是我們在三個文件的這些版本上標(biāo)注標(biāo)記TAG_1，如下圖：圖4.TAG_1標(biāo)記被打到三個文件的不同版本上須要說明的是，標(biāo)記是可以被移動的。這意味著一旦發(fā)覺標(biāo)記打錯了，可以把標(biāo)記移動到別的位置。但在實(shí)踐中，標(biāo)記往往同另一個特別重要的版本限制機(jī)制——代碼分支一起運(yùn)用。在具體探討標(biāo)記(tag)的重要意義之前，我們先來看看代碼分支時什么：圖5.比較困難的情形，一個正在開

發(fā)的項(xiàng)目中的某個文件，已經(jīng)完成了

2.0和2.1的發(fā)布;其中，BP是指劃分

分支的切分點(diǎn)(Branchpoint)所謂代碼分支是版本限制中的一個特別關(guān)鍵的概念。當(dāng)開發(fā)到某個階段的時候，可以交付一個版本，而主要的開發(fā)者則把精力投入到最新版本的開發(fā)中。第一個交付分支(2.0)中的一些問題，以及引入的新功能隨后在RELENG_2分支中被修正，公司確定發(fā)布2.1版本；此后，2.x中的問題接著在RELENG_2中被修正，而一些平安更新，則被合并到2.1-RELEASE中(RELENG_2_1)。圖5展示的是一個文件上的版本分支。實(shí)際的軟件工程項(xiàng)目的源代碼會由大量文件組成，盡管在本質(zhì)上分支是針對每一個文件說的，但在被標(biāo)注了同一分支名稱的文件，就像版本標(biāo)記一樣，能夠表達(dá)一組特定版本文件的集合。cvs的版本分支功能有一個很大的缺陷，即，大量文件的切分點(diǎn)(Branchpoint,即某一個分支最初的版本號)在cvs中很難被指定(cvs支持按某一分支、某一特定時間、某一特定版原來提取文件，但通常不同的文件的版本號并不統(tǒng)一，特殊是在大型項(xiàng)目中，確定有某些文件因?yàn)楸惶峤坏拇螖?shù)很多，而版本號很“高”的狀況)。為了消退這個缺陷，在實(shí)踐上，我們采納版本標(biāo)記和分支結(jié)合的方法，即，在劃分新的分支之后，在這一分支的這些文件的版本上增加一個版本標(biāo)記。例如：對于軟件的2.0版，在劃分時，將切分出RELENG_2(2.x)，RELENG_2_0(2.0)兩個分支，而這時的文件的版本，同時被打上一個RELENG_2_0_0_BP的標(biāo)記。這樣一來，在以后比較版本時，我們可以運(yùn)用RELENG_2_0_0_BP來指定這個版本。當(dāng)不同的分支又增加了很多修改之后，這個標(biāo)記將極大地減輕代碼復(fù)審員的工作量。留意，代碼分支并不僅限于版本上的用法。事實(shí)上，基于同一代碼基礎(chǔ)的多個不同的軟件也可以采納代碼分支的方法進(jìn)行開發(fā)。而最終，這些代碼還可以合并為一個。您可能已經(jīng)留意到最左邊的一組版本序列：1.1,1.2,1.3,1.4,。在cvs中，這一序列被稱為“主分支(MAINBranch)”。盡管并非必需，但習(xí)慣上，主分支通常是活躍的開發(fā)分支。在這個分支中，人們不斷地引入最新的特性，當(dāng)然，不行避開地，這也可能引發(fā)一些問題，而這些引入主分支的問題在隨后將被追蹤、修訂。經(jīng)過一段時間之后，被“沉淀”下來的代碼可以進(jìn)入另一個叫做“穩(wěn)定分支”的代碼系。這樣的開發(fā)模式通常被稱作“多頭并進(jìn)”模式，這樣的模式在很多開放源代碼的軟件開發(fā)中特別常見，例如，Linux的單、雙號版本、FreeBSD的-STABLE和-CURRENT[2]，等等。在一般的商業(yè)軟件開發(fā)中，這種模式也相當(dāng)常見，特殊是在大公司的開發(fā)中。擁有多頭并進(jìn)這一實(shí)力對于大型軟件的開發(fā)尤為重要，因?yàn)榇笮蛙浖芸赡馨喈?dāng)多的模塊，通過版本限制，問題能夠很簡潔地被整個開發(fā)團(tuán)隊追蹤。多頭并進(jìn)的開發(fā)環(huán)境中，開發(fā)人員可以在粗略熟識了某個分支的代碼體系的狀況下參和開發(fā)或維護(hù)，這意味著，即使某個代碼分支的維護(hù)人員突然離去，其他人也不用擔(dān)憂通盤閱讀不同分支的代碼可能造成的理解困難，換言之，對于新的維護(hù)人員的要求被降低，從而，軟件的開發(fā)和維護(hù)過程能夠更為有序地進(jìn)行。據(jù)我所知，F(xiàn)reeBSD的軟件開發(fā)過程極大地得益于多頭并進(jìn)的開發(fā)模式。下面簡潔地介紹一下FreeBSD所采納的軟件開發(fā)模式：

案例：FreeBSD開發(fā)模式中對于多頭并進(jìn)的應(yīng)用FreeBSD包括了兩個主要的開發(fā)分支：4-STABLE和5-CURRENT，以及若干平安分支。其中，4-STABLE(RELENG_4分支)代表的是FreeBSD4.x系列的開發(fā)，其關(guān)注的焦點(diǎn)是系統(tǒng)的穩(wěn)定性和性能；5-CURRENT(HEAD分支)代表的是FreeBSD5.x系列的開發(fā)，它關(guān)注的焦點(diǎn)是盡可能多地引入最新的操作系統(tǒng)特性，全新的設(shè)計思想，等等。除此之外，還有一些被稱作平安分支的分支，它們分別代表FreeBSD2-STABLE,3-STABLE,4.6-RELEASE,4.7-RELEASE,4.8-RELEASE以及即將推出的4.9-RELEASE等等，但這些分支完全不引入任何新的特性，只有平安更新能夠被加入到這些分支中。FreeBSD的“平安分支”是一個特別重要的概念，在FreeBSD的開發(fā)中，這些分支基本上只由一個包括了少量開發(fā)者(目前只有兩人)的，被稱為“FreeBSD平安官”的團(tuán)隊維護(hù)。對于很多用戶來說，他們并不在乎操作系統(tǒng)是否擁有新的特性——他們不情愿嘗試新版本的軟件，因?yàn)楝F(xiàn)有的系統(tǒng)工作的特別好。這些用戶運(yùn)用“平安分支”的FreeBSD操作系統(tǒng)，因?yàn)樗軌蚬?yīng)必要的平安更新，而操作系統(tǒng)特性并不會因此發(fā)生變更(無論這種變更是否能夠改進(jìn)性能，或供應(yīng)一些眩目的功能，甚至支持新的硬件，因?yàn)橛脩舻南到y(tǒng)已經(jīng)放在那里了)。CURRENT分支走的是另外一個極端。全部的新特性，一旦被特定的工作人員(committer)測試通過(大的變更須要核心團(tuán)隊，即coreteam的批準(zhǔn)，但這種狀況并不是很多)，就允許被引入CURRENT分支。盡管CURRENT分支在絕大多數(shù)時間都能夠被正確地編譯，但引入新特性有時會不行避開地帶來一些問題，例如硬件適應(yīng)性問題。在這兩個極端之間，有一條中間路途，即STABLE分支。在CURRENT分支中提交的代碼通常會被指定一個MFC(Mergefrom-CURRENT)時間，在這個時間之后，假如沒有人提交關(guān)于代碼的問題，則這些代碼會被引入STABLE分支。這樣，STABLE分支的代碼幾乎都是經(jīng)過相當(dāng)長時間測試的代碼，對于大多數(shù)用戶來說，STABLE分支是一個很好的選擇。一般來說，F(xiàn)reeBSD中的代碼會經(jīng)驗(yàn)下面的歷程：代碼被引入CURRENT分支相關(guān)開發(fā)者獲得來自用戶的反饋;在確認(rèn)基本沒有問題的狀況下，代碼被引入STABLE分支大多數(shù)最終用戶運(yùn)用STABLE分支的代碼來支持他們的計算機(jī)我們可以看到，上面的開發(fā)模式同時照看到了開發(fā)者和用戶群體的利益。一方面，活躍的開發(fā)不會因?yàn)橛绊懙搅舜罅康囊话阌脩舳獾街肛?zé)；另一方面，在開發(fā)分支(CURRENT)的代碼經(jīng)過一段時間被引入STABLE，最終用戶能夠得到那些新的操作系統(tǒng)功能。事實(shí)上，上述開發(fā)模式已經(jīng)被證明是相當(dāng)勝利的。由于開發(fā)過程中每一天都有相當(dāng)多的人對新的CURRENT和STABLE分支的代碼進(jìn)行測試，因此，在最近的幾年中，F(xiàn)reeBSD的開發(fā)始終呈現(xiàn)著良好的態(tài)勢。交付工程(ReleaseEngineering)基礎(chǔ)——特性凍結(jié)和代碼凍結(jié)很多參和過大型項(xiàng)目開發(fā)的讀者可能都經(jīng)驗(yàn)，至少是聽說過特性凍結(jié)和代碼凍結(jié)這樣一個概念。所謂“特性凍結(jié)”事實(shí)上是一個開發(fā)者之間的約定，在這個階段中，不再允許添加新的功能。特性凍結(jié)(FeatureFreeze)通常在一個開發(fā)分支(DevelopmentBranch)躍變?yōu)榻桓斗种?ReleaseBranch)的時候起先。之所以須要特性凍結(jié)，是因?yàn)樵黾有碌奶匦院苡锌赡芤胄碌膯栴}，而這將給代碼復(fù)審帶來沉重的負(fù)擔(dān)，甚至導(dǎo)致一次不勝利的最終交付。當(dāng)然，對于那些已經(jīng)明確地定義了特性表的小型軟件工程項(xiàng)目(例如，傳統(tǒng)的瀑布開發(fā)模型)來說，特性凍結(jié)沒有什么意義，因?yàn)樵谶@些工程中，具體設(shè)計完全是在編寫代碼之前進(jìn)行的，這意味著，代碼將要寫成什么樣子已經(jīng)在具體設(shè)計中明確地定義。但在實(shí)際的項(xiàng)目中，具體設(shè)計往往會包括兩類不同的類型要求——一部分是“必需實(shí)現(xiàn)的特性(Musthavefeature)”，另一部份則是“希望實(shí)現(xiàn)的特性(DesiredFeature)”。在交付之前，全部“希望實(shí)現(xiàn)的特性”都會在特性凍結(jié)時被明確成“實(shí)現(xiàn)特性”和“不實(shí)現(xiàn)特性”。我們留意到，這種狀況下，某些特性被延遲到接近交付的時候才被明確成“必需實(shí)現(xiàn)”，而另一些“希望實(shí)現(xiàn)的功能”則被作為“不實(shí)現(xiàn)”，從而轉(zhuǎn)化為我們從前熟識的樣子，即具體設(shè)計文檔中明確地定義了軟件中的全部特性。這樣做的結(jié)果是軟件工程項(xiàng)目具有更大的敏捷性。由客戶需求產(chǎn)生的功能設(shè)計，很明顯地，應(yīng)當(dāng)列為“必需實(shí)現(xiàn)的特性”，而那些開發(fā)團(tuán)隊提出的能夠提高軟件整體可擴(kuò)展性、可伸縮性或其他性能的特性，則應(yīng)列為“希望實(shí)現(xiàn)的特性”。在特性凍結(jié)之后，整個開發(fā)團(tuán)隊將專注于那些“實(shí)現(xiàn)特性”(盡管這些特性可能還沒有被正式的實(shí)現(xiàn))更加穩(wěn)定，從而將生產(chǎn)出更高質(zhì)量的軟件。依據(jù)我個人的閱歷，特性凍結(jié)應(yīng)當(dāng)發(fā)生在預(yù)期編碼時間已經(jīng)用去大約2/3的時候。這時，項(xiàng)目經(jīng)理應(yīng)當(dāng)組織開發(fā)人員實(shí)行一次會議探討特性凍結(jié)，而在特性凍結(jié)之后，在軟件正式交付之前，任何開發(fā)人員都不應(yīng)當(dāng)再去考慮那些被列為“不實(shí)現(xiàn)特性”的功能。代碼凍結(jié)是一個和特性凍結(jié)類似的概念，在這個階段，只允許對被凍結(jié)代碼分支中的錯誤進(jìn)行修正，而不允許任何其他的、涉及功能的修改。實(shí)踐上，這個過程中，只有交付工程師(通常是一個或多個對于整個系統(tǒng)架構(gòu)特別了解的、有豐富開發(fā)閱歷的代碼復(fù)審員)被授予審查和批準(zhǔn)代碼提交的權(quán)力，任何代碼修改，只要沒有經(jīng)過交付工程師的批準(zhǔn)，就不能被提交到代碼庫中。代碼凍結(jié)的時間一般不須要太長。對于中等規(guī)模的項(xiàng)目，這一過程通常會持續(xù)一至兩周，對于大型項(xiàng)目，這一過程則有可能持續(xù)一個月甚至更長的時間。在這個階段，交付工程師主要負(fù)責(zé)代碼復(fù)審，而測試工程師則有責(zé)任剛好反饋集中的測試中暴露出的問題，并和相關(guān)的開發(fā)人員聯(lián)系、解決這些問題。技術(shù)上，代碼凍結(jié)可以通過修改cvs中的配置來實(shí)現(xiàn)。不過，更好的方法是通過制度來保證代碼凍結(jié)。交付工程——編碼階段的總結(jié)交付工程的好壞在某種意義上，是干脆關(guān)系到用戶利益的部分。前面已經(jīng)說了相當(dāng)多的關(guān)于軟件開發(fā)過程中通過版本限制技術(shù)來提高開發(fā)效率的技巧和方法，這里我將接著說一說交付工程。前面提到了每日構(gòu)建中在代碼上適當(dāng)?shù)卮蛏习姹緲?biāo)記，以及在劃分版本分支時在切分點(diǎn)上增加版本標(biāo)記，這些對于交付工程都具有特別重要的意義。