軟件公司源代碼管理制度

1、源代碼管理制度(討論稿)一、總則為了加強公司產(chǎn)品、項目開發(fā)源代碼及相關(guān)技術(shù)文檔的管理，進 而確保項目實施的效率和質(zhì)量，特制定本辦法。二、適用范圍產(chǎn)品、項目開發(fā)技術(shù)人員及項目實施負責人。三、定義項是指通過公司立項確定需要按期實施的項目。項目實施：是指為完成立項項目進行的階段性或特定領(lǐng)域的實施過程，主要包括研發(fā)實施和部署實施。源代碼：是指產(chǎn)品、項目研發(fā)過程中所產(chǎn)生的程序源代碼。技術(shù)文檔：是指產(chǎn)品、項目配套的各類設(shè)計文檔、操作手冊等技術(shù)性 文檔。版本管理服務器：指公司架設(shè)供所有開發(fā)人員使用的Subversion(SVN) 服務器。源代碼提交：指開發(fā)人員通過客戶端程序?qū)⑺帉懺创a上傳至版本 管理服務

2、器的操作過程。四、源代碼日常管理流程源代碼管理是技術(shù)研發(fā)過程的日常管理.，上要包括源代碼提交、 源代碼審閱、異常協(xié)調(diào)等兒個環(huán)節(jié)。準備五、源代碼結(jié)構(gòu)設(shè)定源代碼結(jié)構(gòu)是指源代碼在版本管理服務器上存放的文件夾結(jié)構(gòu)。源代嗎結(jié)構(gòu)的設(shè)定由項目實施負責人決定。源代碼結(jié)構(gòu)設(shè)定有幾項基本要求：必須設(shè)置文檔文件夾：每一個獨立項目或子項目源代碼文件內(nèi)， 至少設(shè)定一個docs或doc文件夾以存放僅與該項目相關(guān)技術(shù)文檔 和參考資料；必須考慮支持庫：源代碼結(jié)構(gòu)中，應考慮具體項目所引用的非標 第三方支持庫或框架的存放位置；必須可以直接編譯：源代碼結(jié)構(gòu)必須是可宜接編譯結(jié)構(gòu)。即任何 一臺新裝計算機，在安裝了必要的開發(fā)環(huán)境軟件以后

3、，通過從版 本管理服務器上簽出整套源代碼后，應該可以直接完成編譯。六、500提交500提交是指項R實施期間,所有參與開發(fā)的技術(shù)人員,每日5:00 必須將當日所編制的源碼或技術(shù)文檔提交至版本管理服務器。源代碼及技術(shù)文檔提交有如下幾項要求：任何一次提交都必須對所提交內(nèi)容進行注釋；提交注釋必須包含的信息項包括：所屬模塊或功能（必須與項目 實施進度計劃一致）、性質(zhì)（正常開發(fā)、修改BUG、擴展功能）、 狀態(tài)（編碼中（x%）、調(diào)試通過、獨測通過、聯(lián)測通過）、更新說 明（本次提交所涉及修改部分的簡要說明）。提交注釋必須以下圖示例格式為準。Message:（ Recent messagesI質(zhì)顯一拄忒功應廢如

4、法充題隹想.正知線然杰微硬勺（80+）更至說理。己經(jīng)買羽毯咬條仔趣苦亙以懣過五谷專魂運三金品.龍三? 黑！I的舞E暴兼基融二愛溟整J所提交源碼必須是編譯無錯版本。七、530審閱530審閱是指項目實施負責人，每II下班前審閱版本服務器上所有下屬技術(shù)人員所提交的源代碼和技術(shù)文檔。源代碼審閱布以下兒點審閱標準：下屬技術(shù)人員必須全員按時提交；所7T提交必須附rr符合要求的提交注釋；各人所提交的內(nèi)容必須與既定的項H實施進度計劃安排一致；審閱過程中，凡不符合上述任一條標準的，則表示當日源碼提交 出現(xiàn)異常。項目實施負責人應立即進行協(xié)調(diào)，未按時提交者督促其即 刻提交；沒有附提交注釋或注釋不符介要求者，補充提交

5、注釋；提交 內(nèi)容與既定項目實施進度計劃安排不一致者，要進行溝通和協(xié)調(diào)，保 證參與實施人員的每H工作均按既定計劃分步實施。八、進度計劃更新項口實施負責人，通過53()審閱和必要的簡短溝通，確認各在執(zhí) 行子任務的真實進度，并以此為準更新進度計劃文檔。九、版本庫布局版本庫按項FI布局，每一個項目建立一個獨立的版本庫，項目版 本庫下設(shè)置trunk和branches兩個文件夾，分別用于存放原始項目 資料和起源于原始項目的分支項Ho每個項目分支都應該有含義明確的命名，并以分支名稱在 branches文件夾下建立子文件夾。分支文件夾的結(jié)構(gòu)與trunk文件 夾結(jié)構(gòu)一致。trunk文件夾下設(shè)置working和l

6、ocked兩個文件夾，其中 working為工作文件夾，參與項目的開發(fā)人員有改寫權(quán)限。locked文 件夾為定版文件夾，項目開發(fā)人員無權(quán)訪問，項目實施負責人有改寫 權(quán)限，品監(jiān)部有簽出權(quán)限。working文件夾下設(shè)置docs和projects兩個文件夾，其中docs 文件夾存放項目相關(guān)設(shè)計文檔，projects文件夾存放各子項目工程 文件夾。docs和projects文件夾以下子文件夾結(jié)構(gòu)不做限定，但對于C/S 類項目建議在projects文件夾下設(shè)置server和client兩個文件夾, 分別存放服務端子項目資料和客戶端子項n資料。十、項目定版項目定版是指項目研發(fā)實施到某個進度計劃中設(shè)定的里程

7、碑狀 態(tài)或其他特定狀態(tài)時，整體提交的一個階段性版本。一些既定的定版 包括：系統(tǒng)聯(lián)機調(diào)試定版、內(nèi)測定版、演示定版、實測定版、發(fā)布定 版、升級定版。對于項目定版有如下要求：項目所有子項目、子模塊源碼均編譯無錯;編譯所成系統(tǒng)可聯(lián)機運行；所有技術(shù)文檔與實現(xiàn)源碼一致；項目定版由項目實施負責人組織實施，實施過程在源代碼庫上面 體現(xiàn)為：working文件夾下最新版本的源碼和文檔被一次性完整的提 交到locked文件夾。項目定版操作建議：將locked文件夾檢出(Checkout)一個副本到本地文件夾； 將 workingdocs 和 workingprojects 兩個文件夾導出(Export)到locke

8、d副本文件夾，覆蓋locked文件夾下的原文件； > 提交(Commit) locked 文件夾;項目定版提交必須附提交注釋，注釋內(nèi)容必須包含的項目包括： 定版目的（聯(lián)機調(diào)試、內(nèi)測、演示、實測、發(fā)布、升級）、版本特性。 其中版本特性要進行詳細說明。如果是笫一個定版，版本特性應詳細 列舉已經(jīng)實現(xiàn)的功能，后續(xù)定版提交注釋的版本特性說明則只需寫明 新版本較上一-個版本的新特性。十一、項目既定定版說明既定定版是指在項目研發(fā)實施過程中的必須設(shè)定的兒個階段性 版本。聯(lián)機調(diào)試定版：是指項口整體設(shè)計中的所有子系統(tǒng)和子模塊都已 經(jīng)完成基礎(chǔ)開發(fā)，在研發(fā)實施團隊內(nèi)部進行完整系統(tǒng)聯(lián)機調(diào)試通 過以后的版本。聯(lián)機調(diào)

9、試版本中的各個子系統(tǒng)和子模塊不需要完 整實現(xiàn)了所有既定功能，也不需要達到既定設(shè)計性能，可以存在 BUG,其主要作用是為研發(fā)實施團隊自身構(gòu)建一個可供各功能模塊 進行聯(lián)機調(diào)試的系統(tǒng)環(huán)境，并確認系統(tǒng)整體設(shè)計的可實施性。聯(lián) 機調(diào)試定版后，研發(fā)實施團隊應撰寫系統(tǒng)部署手冊草案；內(nèi)測定版：是指移交品監(jiān)部進行系統(tǒng)測試的版本。內(nèi)測版本應該 是通過若干次聯(lián)機調(diào)試，并且已經(jīng)解決了所有聯(lián)機調(diào)試過程中所 發(fā)現(xiàn)問題以后的版本。內(nèi)測定版不一定實現(xiàn)了所有的功能，但已 經(jīng)實現(xiàn)的功能應該具備基本的穩(wěn)定性；演示定版：是指通過若干次內(nèi)測之后，不存在特別嚴重缺陷，可供商務人員向客戶進行產(chǎn)品功能和性能演示的版本。演示定版不一定實現(xiàn)了所有的功能，也不一定達到系統(tǒng)既定設(shè)計性能。實測定版：是指通過若干次內(nèi)測之后，不存在影響正常使用的缺 陷，可供在客戶真實環(huán)境試用的版本。實測定版應該實現(xiàn)了所有 核心功能，允許少量存在不確定因素的功能缺失；發(fā)布定版：是指通過若干次內(nèi)測和實測之后，已經(jīng)實現(xiàn)了所有既 定