配置管理及版本控制介紹-V1.8

2023/11/271軟件配置管理

(SoftwareConfigurationManagement)2023/11/272課程內容什么是配置管理版本控制程序配置管理工具發(fā)布過程控制2023/11/273目的了解配置管理學習定義版本了解配置管理工具學習發(fā)布過程控制2023/11/274一個問題例子軟件出問題了…

我馬上解決這個問題（忘了變更登記）2023/11/275結果…仍然有問題…

我已經改過了>_<2023/11/276軟件開發(fā)中的一系列普遍問題缺乏可視性不受控的變更缺少監(jiān)控缺乏可跟蹤性缺乏控制配置管理2023/11/277配置管理給我們帶來了什么好處問題提高軟件開發(fā)生產率為配置管理設置專門的智能人員，并且要有一些軟硬件環(huán)境支持，都增加了開發(fā)的成本降低軟件維護費用確保構建正確的系統(tǒng)更好的質量保證減少缺陷對于簡單系統(tǒng)的開發(fā)沒有實際的意義使軟件開發(fā)依賴于過程而不是依賴于人2023/11/278軟件配置管理的概念軟件配置管理SCM，通過一套工程規(guī)范，在整個軟件生命周期中跟蹤、記錄軟件，保證全部變更都記錄在案，并保證軟件的當前狀態(tài)是已知的和可重復的。

規(guī)范工具配置管理人2023/11/279配置管理金字塔HOW2023/11/2710配置項

（ConfigurationItem）配置項是處于配置管理之下的軟件或硬件作為一個實體出現(xiàn)的集合體。包括交付給顧客的軟件產品，及用以創(chuàng)建這些軟件產品的其它項。通常標識配置項有：管理計劃（SDP,SQAP,Testplan,SCMP,etc.)需求和設計文檔；用戶和維護文檔及手冊；測試文檔，測試驅動，及數(shù)據；支持軟件（包括編譯器和操作系統(tǒng)）；2023/11/2711基線（Baseline）已經通過正式復審和批準的某規(guī)約或產品可以作為進一步開發(fā)的基礎且只能通過正式的變更控制過程來改變基線是經過技術評審而批準的一組配置項。對基線的更改必須遵循變更控制規(guī)程。2023/11/2712典型過程綠線為時間軸紅線為基線化的文檔或文件交付的產品系統(tǒng)需求軟件需求設計規(guī)格說明需求分析軟件設計編碼/單元測試軟件集成測試驗收測試代碼待交付的產品維護基線13配置庫的劃分配置庫的劃分開發(fā)庫配置庫產品庫客戶項目級配置管理員控制項目組成員控制評審評審公司級配置管理員控制CheckinCheckoutCheckoutCheckinCheckoutCheckin2023/11/2714課程內容什么是配置管理版本控制程序配置管理工具發(fā)布過程控制2023/11/2715版本控制

對軟件開發(fā)進程中文件或目錄的發(fā)展過程提供有效的追蹤手段，保證在需要時可回到舊的版本，避免文件的丟失、修改的丟失和相互覆蓋。版本控制是實現(xiàn)團隊并行開發(fā)、提高開發(fā)效率的基礎。2023/11/2716版本號定義版本號定義:

用來標識開發(fā)、測試、交付階段的不同狀態(tài)的產品。格式：

Ｖ＜主版本號＞．＜副版本號＞．＜Ｒｅａｌｓｅ號＞如：

V1.0.2Ｒｅａｌｓｅ號：又叫Ｂｕｉｌｄ號，內部測試開始之前設置，初始值為０，此后每產生一次小的修改，Ｒｅａｌｓｅ號＋１架構發(fā)生改變、構件進行重大修改，

主版本號＋１2023/11/2717源代碼標識以系統(tǒng)為單位建立標簽＜產品英文簡稱＞＿Ｖ〈主版本號＞．＜副版本號＞．＜ｒｅｌｅａｓｅ號＞ｒｅｌｅａｓｅ號初始值為０如：MCA_V2.0.0以軟件單元（子系統(tǒng)／組件／模塊）為單位建立標簽：＜產品英文簡稱＞＿＜軟件單元英文簡稱＞＿Ｖ〈主版本號＞．＜副版本號＞．＜ｒｅｌｅａｓｅ號＞如：MCA_ANDROID_APP_V2.1.02023/11/2718文檔標識公司項目文件命名：＜產品英文簡稱＞+＜文檔類別/相應工作產品名稱＞+＜項目版本號＞（通常文檔版本號在文檔內部修訂記錄中體現(xiàn)）如：MCA項目計劃V2.0.doc文檔的標簽與源代碼的標簽應保持一致，即當每次給源代碼打標簽時，同時應給源代碼所依據的技術文檔及其對應的測試文檔和用戶文檔打上同樣的標簽。2023/11/2719文檔修訂記錄日期版本作者修改內容備注2014/8/40.1譚款擬稿初稿2014/8/50.2譚款重新定義文檔結構識別、分類配置項配置庫分類、角色權限定義內容定義2014/8/60.3樊顯斯工作產品分類版本控制新增基線意義和內容細節(jié)新增版本控制、基線管理模塊2014/8/110.4譚款添加使用指南章節(jié)快速入門2014/12/51.0譚款正式稿

文檔版本包含于文檔內容中，“修訂記錄”章節(jié)。起草版本的編號為0.1,0.2,...,0.3.一旦文檔版本得以確認后，版本編號應該始自1.0。修訂記錄2023/11/2720變更控制過程是否通過？駁回歸檔通過分派給開發(fā)者Checkout變更評審評審提交申請驗證驗證生成初始變更請求請求變更實施變更執(zhí)行核實變更結果Checkin核實結束結束通知申請人結束需求變更功能增強功能欠缺2023/11/2721變更評價技術影響分析接口影響分析成本影響分析進度影響分析變更分類變更評價2023/11/2722課程內容什么是配置管理版本控制程序配置管理工具發(fā)布過程控制SVN版本控制工具基于Subversion和TortoiseSVN的版本控制系統(tǒng)Subversion：是一個開源的版本控制系TortoiseSVN：SVN的客戶端工具。復制-修改-合并方案(Subversion默認的模式)鎖定-修改-解鎖方案

在一個時間段里配置庫的一個文件只允許被一個人修改。此模式不適合軟件開發(fā)這種工作。獲取項目文件——CheckOut將版本庫中的內容檢出到本地工作副本步驟：1、新建一個空文件夾；比如：E:\MCA2、在此目錄中點擊右鍵->SVNCheckout...3、輸入項目SVN路徑，比如：svn://192.168.1.130/mca/<待檢出的子目錄>同步項目文件——Commit對工作副本進行編輯后提交到SVN，在右鍵菜單中點擊SVNCommit。提交前寫好log，點擊確定如多人同時操作同一文件，提交前先進行Update操作避免沖突。SVN操作介紹——Update作用：更新工作副本使其成為版本庫中的最新版本SVN將顯示出更新的文件和更新的次數(shù)SVN操作介紹——ShowlogSVN操作介紹——獲取歷史版本工作副本右鍵顯示日志選擇所需的版本號保存版本至SVN操作介紹——編輯沖突關于提交的建議為避免沖突修改文件之前，先進行一次update操作修改完成后，及時commit，不要在本地停留過長時間在多位團隊成員協(xié)作時，盡量修改自己撰寫的部分，盡量不要修改不屬于自己撰寫的部分出現(xiàn)沖突很正常，可以通過前面的方法解決，不要相互覆蓋log填寫規(guī)則好的日志信息和糟糕的日志信息日志信息主要記錄的是每次的修改內容。建議把一些重要數(shù)據、關鍵操作寫到日志信息中。注：修改人和提交時間由軟件自動記錄，無需人工寫入日志信息不規(guī)范的日志規(guī)范的日志去除無用文件刪除分支中的無用文件attachment.js_BAK_和moderation.js”線索報警修改線索的樣式更新配置文件更新公司主題包和欄目配置文件2023/11/2732配置管理目標配置管理版本控制過程控制異地開發(fā)支持變更請求管理工作空間管理并行開發(fā)支持2023/11/2733課程內容什么是配置管理版本控制程序版本管理工具發(fā)布過程控制準備提測1、檢查確認所有成員代碼均已提交至SVN，并確保在trunk下的代碼測試無誤；2、所有文檔提交至對應文件夾（包括研發(fā)文檔：《需求功能列表》、《版本發(fā)布報告》，酌情編寫設計文檔及單元測試報告、用戶文檔：《產品使用說明書》、《安裝部署手冊》、《技術白皮書》、《產品介紹》等）版本備份-TAG將開發(fā)庫中的內容備份到標簽：步驟：1、、右鍵選擇trunk，選擇“copyto”，輸入tags的路徑及備份標簽名稱。如：svn://192.168.1.130/ACA/tags/ACA_V1.0.12、修改標簽路徑，輸入標簽名稱3、點擊確定后，備份出現(xiàn)在Tags中注意：版本相關文檔和代碼同步備份2023/11/2736編譯打包根據Tag對應版本的代碼進行編譯打包。產品包必須與生成它的源代碼版本保持一致，從而保證其與源代碼之間的一致性。產品包命名：[項目英文簡稱]+[代碼版本編號]

如：MCA_V2.0.0產品包分為完整版和升級版兩種。應根據該產品以前版本的客戶使用情況以及升級安裝需求，制作升級版。申請測試步驟：1、項目經理將提測版本提交至開發(fā)庫；地址：\\192.168.1.46\開發(fā)庫\MCA\<產品包>；發(fā)布包：包含根據Tab打包的可執(zhí)行文件及版本相關文檔（《版本發(fā)布報告》、《產品使用說明》、《部署說明書》、《產品功能列表》等。2、發(fā)送申請測試郵件（提測郵件）38提測郵件模板主題：

GSA_V1.5.2提測申請<簡要說明本次主要修改內容和測試重點>版本基本信息：1、SVN標簽：

svn://192.168.1.130/aca/tags/ACA_V1.5.22、測試軟件包：\\192.168.1.46\開發(fā)庫\ACA\提交區(qū)\ACA_V1.5.2\software<提測內容截圖>39確認測試測試負責人發(fā)出測試通過通知，配置管理員根據郵件內容進行基線備份，將發(fā)布包備份至配置庫。運維人員從配置庫提取發(fā)布包進行預發(fā)布測試。測試通過，走發(fā)布流程，審批通過方可發(fā)布版本。40配置庫結構配置庫的劃分開發(fā)庫配置庫產品庫客戶項目級配置管理員控制項目組成員控制評審評審公司級配置管理員控制CheckinCheckoutCheckoutCheckinCheckoutCheckin2023/11/2741受控->基線42發(fā)布項目經理根據《軟件發(fā)布流程》進行發(fā)布申請流程。發(fā)布內容由配置管理員提供。步驟：1、開發(fā)、測試、運維根據《軟件測試情況檢查清單》對測試情況進行確認；2、配置管理員、安全管理員對《軟件發(fā)行檢查清單》進行檢查；3、總經理審批通過后，根據《軟件發(fā)放通知單》進行軟件發(fā)放?！盾浖l(fā)放通知單》總經理審批后方可發(fā)布。43資料歸檔項目經理根據《軟件發(fā)放通知單》對軟件完成發(fā)放后將項目資料提交歸檔。步驟：1、根據