跳轉到內容

版本管理

0% developed
來自華夏公益教科書

版本管理是指軟體專案中版本週期的管理,版本週期是指軟體工程師提供一組唯一標識的檔案供其他人使用。其他人可能是他們工作中的部門、大學裡的同學或全世界。這組檔案(可能是一個檔案)構成了軟體版本。管理版本意味著版本管理者知道

  • 它包含了什麼
  • 它去了哪裡
  • 為什麼它去那裡
  • 如何處理報告的錯誤

構建軟體是應用於將原始碼編譯或聚合為可使用工具或應用程式的通用術語。原始碼不需要以傳統意義上的方式進行編譯(構建),傳統意義上的編譯依賴於編譯器將檔案連結在一起;現代系統可能完全由解釋的原始碼檔案組成(例如,Perl 或 PHP 的原始碼檔案)。不過,將所有內容組合在一起,使其成為可使用格式,仍可以被認為是“構建”。

軟體專案越大越複雜,對極其完善的構建和釋出功能的需求就越大。

構建和釋出過程具有幾個特徵。最常見的是使用隔夜構建、規範化的構建編號、高度自動化、排程和重用、使用通知、元資料捕獲和儲存,以及專案門戶或檢視器的實現。

隔夜構建

[edit | edit source]

這是一個基本功能,它實現兩個主要目標

  1. 它建立了專案的程式碼整合。
  2. 它立即提醒您程式碼整合出現問題。

這些聽起來像是同一件事,但實際上並非如此。軟體工程師期望隨著專案的成熟看到程式碼整合;隔夜構建確認了這一點。他們不希望看到程式碼整合出現問題(“昨天構建成功,但今天失敗”問題),因此他們希望在遇到問題時立即知道。工程師應該是唯一看到合法程式碼整合問題的人。他們應該在進行單元測試時發現並解決問題,然後再提交到專案中。透過執行隔夜構建,工程師最多隻有 24 小時的原始碼更改需要審查和/或回退,如果構建出現問題。

隔夜構建還為 QA 部門提供了執行測試用例和針對特定錯誤迴歸的目標。隔夜構建透過減少解決實際程式碼整合問題所需的時間來幫助軟體專案團隊按時完成任務。

有效的構建編號

[edit | edit source]

當團隊每天晚上(或持續)構建專案時,就需要構建編號方案以及構建釋出規則。構建釋出規則是指哪些構建釋出到 QA 用於消費,以及該釋出的目標。在特定機器上的特殊目錄結構足以滿足此目的。專案團隊成員在專案開始之前就確定了這一點,開始使用它,並在專案的整個過程中不進行更改。在整個專案週期中,任何相關方都可以快速檢視任何構建。編號方案必須足夠靈活,以便在編號本身中提供特定的、內建的含義。例如

foobar20110

此構建“編號”允許視覺化識別其內容。專案中的任何人都可以檢視此編號,並知道構建包含

  • Foobar
  • 版本 2 原始碼
  • 內部構建編號 110

版本管理者和構建工程師必須建立一個可以透過自動構建指令碼輕鬆遞增的編號方案。

自動化

[edit | edit source]

人為錯誤對於諸如編寫電子郵件之類的瑣碎的一次性操作來說是可以接受的風險。但對於構建和釋出軟體來說,人為錯誤是不可接受的風險。如果該程式的步驟可以輸入到鍵盤中,那麼該程式很可能可以實現自動化。設計良好的自動化模組可以在專案中的其他地方以及其他獨立專案中重複使用。

自動生成的構建編號

[edit | edit source]

在原始碼中嵌入構建編號是一種常見做法。這允許軟體應用程式的使用者開啟“關於”或“版本”螢幕,並接收有關應用程式版本和構建編號的資訊。這在支援和升級情況下很有用。使用者會看到類似於“版本 12.3 構建 1234”的內容。這些字串來自原始碼,通常是在構建之前進行手動編輯得到的。該過程——生成構建編號並將其插入原始碼——可以實現自動化。版本工程師必須開發一個指令碼或其他自動化程式碼,該程式碼讀取主構建編號檔案,遞增並快取它,開啟包含構建和版本字串的原始碼檔案,對檔案中的字串進行 grep 或搜尋,進行替換,關閉檔案,提交併標記它。現在,構建編號已在構建過程之前放入原始碼中。

排程

[edit | edit source]

執行良好的版本管理類似於軟體開發專案的其他方面,因為它高度依賴於已安排任務的完成情況。構建是產生版本管理過程工件的最重要的一項已安排任務。版本管理者必須確保構建時間表是可以預測的並且得到維護。實現這一目標的一種機制是使用 cron 或 at 等作業排程器。這使版本管理者能夠建立一個用於構建、釋出和部署的自動執行的時間表。

重用

[edit | edit source]

重複使用自動化模組使版本管理者能夠將更多活動壓縮到可用時間內,從而提高生產力,而無需相應地增加動手工作量。可以在專案內部和專案之間重複使用的自動化模組示例包括用於電子郵件通知、原始碼檢出和檢入、檔案複製以及部署的那些模組。

通知

[edit | edit source]

對於版本工程師來說,能夠收到任何給定版本或構建過程成功或失敗的通知是有利的。版本過程中的自動通知提供了這一點。在構建結束時,可以向專案團隊傳送一個簡單的“構建正常”訊息。該訊息可能包含指向包含詳細資訊的日誌檔案的超連結,團隊可以從快速接收狀態中獲益。類似地,當構建出現問題時,通知會立即以“構建失敗”訊息提醒團隊,以便進行調查。

專案門戶

[edit | edit source]

網路伺服器易於部署,並已成為構建和釋出元資料展示管理器的流行工具。專案成員和其他相關人員可以透過網頁瀏覽器檢視頁面,以獲取適合其目的的專案狀態詳細資訊。有幾種成熟的工具可以用於此目的,包括 Anthill、CruiseControl 和 BuildMaster。

資料庫儲存

[編輯 | 編輯原始碼]

構建和釋出軟體會產生大量的元資料,其數量和重要性都非常大。釋出經理對以下方面感興趣:

  • 構建和釋出趨勢,這些趨勢可以幫助洞察如何改進未來的釋出週期。
  • 審計日誌,這些日誌提供特定軟體更改遷移的歷史記錄。

構建元資料的示例包括:

  • 構建編號
  • 構建日期
  • 構建版本
  • 使用的原始碼標籤
  • 隔夜構建 (Y/N)
  • QA 測試 (Y/N)
  • QA 測試結果 (透過/失敗)
  • 完整日誌的位置

釋出經理可以使用任何關係型資料庫管理系統 (RDBMS);有幾種 RDBMS 是免費提供的,可以快速設定在執行任何免費作業系統的低成本計算機上。可以匯入現有的構建日誌以用於歷史資料儲存。構建元資料可能因專案而異,一般認為儲存的元資料量存在實際限制。例如,即使釋出經理可能捕獲並存儲諸如“構建中包含的二進位制檔案數量”等資料,也必須考慮這些資料是否有意義。僅僅因為資料可用,並不意味著它自動就成為資訊。

華夏公益教科書