軟件版本控制規(guī)范

1、軟件版本控制規(guī)范Date of Issue: 2012/08/06Version: 1.0 For All Team MembersRevision HistoryDateVersionDescriptionAuthor2011-08-06draftEfun2011-08-20draft調(diào)整了文檔的結(jié)構(gòu)，增加了版本控制相關(guān)的內(nèi)容Efun1目的12適用范圍13職責(zé)13.1開發(fā)人員13.2發(fā)布人員14工作程序14.1項目開發(fā)人員注意事項14.2版本管理策略2軟件版本控制規(guī)范 1 目的 規(guī)范部門軟件產(chǎn)品版本升級流程，清晰管理版本號，加強(qiáng)不同版本軟件保存的可靠性。 2 適用范圍 適用于開發(fā)結(jié)束進(jìn)行測試

2、或投入應(yīng)用的軟件系統(tǒng)的升級或變更管理。 3 職責(zé) 3.1 開發(fā)人員開發(fā)人員負(fù)責(zé)代碼的開發(fā)，開發(fā)的代碼需提交到正確的svn地址。3.2 發(fā)布人員發(fā)布人員負(fù)責(zé)代碼的發(fā)布，發(fā)布的代碼需根據(jù)release note從svn獲得，發(fā)布后需向所有相關(guān)人員發(fā)送成功的郵件，并更新JIRA上的狀態(tài)。4 工作程序 4.1 項目開發(fā)人員注意事項4.1.1 開發(fā)人員每天早上至少從svn上update一次代碼，下班前需再次update代碼后，將修改的代碼commit到svn。4.1.2 開發(fā)人員更新或提交代碼時如果發(fā)現(xiàn)有代碼沖突，需立即找代碼沖突的相關(guān)人員查找原因，嚴(yán)禁直接強(qiáng)制提交。4.1.3 發(fā)布代碼到uat和生產(chǎn)機(jī)

3、需由專門的發(fā)布人員操作，每次發(fā)布到uat和生產(chǎn)機(jī)，需在JIRA上登記。4.1.4 發(fā)布人員只接收release note，發(fā)布人員根據(jù)release note從svn拉下代碼并打包，不接收開發(fā)人員拷貝的代碼文件。4.1.5 發(fā)布代碼到生產(chǎn)機(jī)需根據(jù)release note生成check list，由開發(fā)人員和發(fā)布人員根據(jù)check list檢查無誤后進(jìn)行發(fā)布，release note和check list的結(jié)果需在svn上留檔。4.1.6 發(fā)布生產(chǎn)機(jī)成功后，發(fā)布人員需向所有相關(guān)人員發(fā)送成功的郵件，并更新JIRA上的狀態(tài)。4.2 版本管理策略4.2.1 代碼分支的管理4.2.1.1 代碼分支管理示

4、意圖參見圖.1圖4.2.1.14.2.1.2 代碼分支管理策略在使用版本控制系統(tǒng)時，必須考慮如何設(shè)置分支結(jié)構(gòu)?？梢酝ㄟ^鏡像源代碼文件來創(chuàng)建一個分支。然后，可以在不影響源的情況下更改該分支。例如，如圖4.2.1.2.1的分支結(jié)構(gòu)所示，MAIN 分支包含已通過集成測試的已完成功能，而 DEVELOPMENT 分支包含團(tuán)隊正在構(gòu)建的代碼。當(dāng) DEVELOPMENT 分支中的新功能完成并可通過集成測試時，可以將代碼從 DEVELOPMENT 分支提升到 MAIN 分支中。此過程稱為“反向集成”。反之，如果將代碼從 MAIN 分支合并到 DEVELOPMENT 分支中，則此過程稱為“正向集成”。圖4.2

5、.1.2.1分支和合并需要遵循下列原則：1.每個分支都必須具有一個定義的策略，此策略與如何將代碼集成到相應(yīng)分支中有關(guān)。例如，在圖.2.1的分支結(jié)構(gòu)中，可以指定一個團(tuán)隊成員來擁有和管理 MAIN 分支。該成員負(fù)責(zé)執(zhí)行初始分支操作、將更改從 DEVELOPMENT 分支反向集成到 MAIN 分支，以及將更改從 MAIN 分支正向集成到 DEVELOPMENT 分支。當(dāng) MAIN 分支也從其他分支集成更改時，正向集成非常重要。2.MAIN 分支必須包含已通過集成測試的代碼，以便始終準(zhǔn)備進(jìn)行發(fā)布。3.由于團(tuán)隊成員會定期簽入更改，因此 DEVELOPMENT（或工作）分支將不斷演變。4.標(biāo)簽(tag)是

6、分支中的文件在某個特定時間的快照。反向集成和正向集成的頻率：反向集成和正向集成應(yīng)至少在用戶情景完成時進(jìn)行。雖然每個團(tuán)隊對于完成的定義可能不同，但完成用戶情景通常意味著完成了功能和對應(yīng)的單元測試。只能在單元測試驗證 DEVELOPMENT 分支的穩(wěn)定性后反向集成到 MAIN 分支中。如圖4.2.1.2.2所示。圖4.2.1.2.2如果具有多個工作（即 DEVELOPMENT）分支，則當(dāng)任意分支集成到 MAIN 分支時應(yīng)立刻正向集成到所有工作分支。因為 MAIN 分支保持穩(wěn)定，所以正向集成是安全的。工作分支中可能會發(fā)生某些沖突或失敗，這是因為無法保障工作分支是穩(wěn)定的。應(yīng)盡快解決所有沖突，這非常重要

7、。4.2.1.3 添加分支的時機(jī)以下情況下應(yīng)創(chuàng)建分支：在必須按與現(xiàn)有分支不同的時間表/周期發(fā)布代碼時。在代碼需要不同的分支策略時。如果創(chuàng)建具有新策略的新分支，則可以為項目增添策略價值。在向客戶發(fā)布功能且團(tuán)隊打算進(jìn)行不影響計劃的發(fā)布周期的更改時。不應(yīng)對每個用戶情景創(chuàng)建分支，因為這會產(chǎn)生較高的集成成本。雖然通過 可方便地進(jìn)行分支，但在分支很多時，管理分支的開銷可能會很大。4.2.1.4 從版本控制的角度，關(guān)于發(fā)布的管理團(tuán)隊?wèi)?yīng)能在任意沖刺 (sprint) 末尾發(fā)布代碼。可以標(biāo)記(tag)一個分支以在某個特定時間點(diǎn)為代碼拍攝快照。如圖4.2.1.4.1所示，可以為發(fā)布標(biāo)記 MAIN 分支。這樣，就可

8、以將分支返回到此時間點(diǎn)時的狀態(tài)。注意只有已反向集成到MAIN 分支的代碼才能被發(fā)布。圖4.2.1.4.1在為發(fā)布創(chuàng)建分支時，應(yīng)從 MAIN 分支（該分支最穩(wěn)定）創(chuàng)建分支。如果從工作分支對發(fā)布進(jìn)行分支，則會導(dǎo)致集成問題，因為無法保證工作分支的穩(wěn)定性。4.2.1.5 分支或標(biāo)簽(tag)的命名版本號Smartphone_20110905代號ab代號說明a項目代號，首字母大寫，推薦使用駝峰式命名。b創(chuàng)建日期，4位年，2位月，2位日，位數(shù)不夠補(bǔ)0。例：Smartphone項目在2011年9月5日創(chuàng)建了一個分支，則分支命名為Smartphone_201109054.2.2 版本號的含義版本號3.5.0.

9、0vi-update1.0.0代號abcdefgh代號說明a大版本號，代表一次重要的系統(tǒng)升級。上線前為0，上線后從1開始計數(shù)，每一次重要的系統(tǒng)升級后計數(shù)加1。b小版本號，代表一次比較大的系統(tǒng)升級。從0開始計數(shù)，每一次比較大的系統(tǒng)升級后計數(shù)加1。c次版本號，代表一次生產(chǎn)機(jī)系統(tǒng)更新，如CR，或bug的修復(fù)。從0開始計數(shù)，每發(fā)布一次生產(chǎn)機(jī)后計數(shù)加1。d內(nèi)部版本號，代表一次測試系統(tǒng)更新。從0開始計數(shù)，每發(fā)布一次測試機(jī)后計數(shù)加1；次版本號計數(shù)加1時，計數(shù)歸零。e只在非主干分支上標(biāo)示，代表開發(fā)的項目代號f只在非主干分支上標(biāo)示，對應(yīng)開發(fā)的項目的第幾個分支。從1開始計數(shù)，對應(yīng)開發(fā)的項目每創(chuàng)建一個，計數(shù)加1。g

10、只在非主干分支上標(biāo)示，分支次版本號，代表一次生產(chǎn)機(jī)系統(tǒng)更新，如CR，或bug的修復(fù)。從0開始計數(shù)，每發(fā)布一次生產(chǎn)機(jī)后計數(shù)加1。(一般開發(fā)分支需要合并到MAIN分支上才能發(fā)布到生產(chǎn)機(jī)，只有當(dāng)開發(fā)分支代碼獨(dú)立為一套新的應(yīng)用，在生產(chǎn)機(jī)上有新的url訪問路徑時，才能發(fā)布到生產(chǎn)機(jī))h只在非主干分支上標(biāo)示，分支內(nèi)部版本號，代表一次測試系統(tǒng)更新。從0開始計數(shù)，每發(fā)布一次測試機(jī)后計數(shù)加1；次版本號計數(shù)加1時，計數(shù)歸零。在不造成誤解的前提下，溝通時分支版本號可使用簡稱，簡稱只取e、f、g、h位。如果基于分支又打了一個分支，則版本號在原來分支的基礎(chǔ)上再增加e、f、g、h位，以此類推。例：假設(shè)原來生產(chǎn)環(huán)境的代碼在M

11、AIN分支上，版本號為，現(xiàn)在有一個名為 NewProject的項目，且NewProject項目在生產(chǎn)機(jī)有自己新的url，則：基于MAIN分支新建的第一個開發(fā)分支的第一個測試版本為3.5.10.0 NewProject 1.0.0，簡稱NewProject 第一個開發(fā)分支的第二個測試版本為 0.0 NewProject 1.0.1，簡稱NewProject 0.0 NewProject 1.0.1測試通過后放到生產(chǎn)機(jī)，則第一個開發(fā)分支的生產(chǎn)機(jī)版本也為0.0 NewProject 1.0.1之后，基于新建的NewProject項目第二個開發(fā)分支的第一個測試版本為3.5.10.0 NewProject 2.0.0，簡稱NewProject 2.0.0第二個開發(fā)分支的第二