968
《配置管理最佳實踐》——2.3 構建工程的核心概念
本節書摘來自異步社區《配置管理最佳實踐》一書中的第2章，第2.3節，作者： 【美】Bob Aiello , Leslie Sachs著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
2.3 構建工程的核心概念
成功的構建工程都包含如下職責：首先構建的依賴關係易被理解且受控，基線是可識別的，在此基礎上可重複地生成構建。每次構建都是針對配置項的活動。構建包含配置項，並且可產生新的配置項。幾乎構建中的任何東西都可以被認為是配置項。構建工程師的首要任務，是核實所有的可執行文件、重要的腳本、文檔和文本文件已被正確地識別和標識。
2.3.1 版本ID和標記可執行文件
構建工程師既能輕而易舉地識別出源代碼基線，也能輕鬆地確定構建產物的版本。這包括所有的二進製文件（中間代碼和運行時模塊）以及所有的配置文件。正如第1章配置管理術語中提到的，我們稱這些產物為配置項，無論它們是源代碼、二進製文件還是配置文件。在理想的情況下，一切事物都有一個不變的版本ID作為標識。實際上我們已經習慣了通過查看應用程序的“關於”框看產品的版本。所有的文檔，包括發布說明、教程和技術說明等，都應該包含版本信息。這樣，我們就能很容易地知道它們對應的是源代碼的哪一個版本。
2.3.2 不可變的版本ID
對可執行文件最基本的要求就是給它們一個不可變的版本ID，然後提供簡單的程序來檢索版本ID。對於C++程序，通常可以把版本ID設置成一個靜態的char 類型變量，然後把它打在可執行文件上。對於JAVA程序，可以寫一個JAVA類去定義版本ID，然後把版本ID寫到構建過程生成的JAR,WAR, 或EAR的 manifest文件中去。關鍵在於確保通過可執行程序的版本ID可以很容易地追溯到生成它的源代碼版本。
2.3.3 打上版本標記或者標簽
在某些情況下，發布構建的時候，我們會把源代碼管理工具的版本標簽或者標記打在可執行文件上。因為在源代碼原理工具中，當用於發布的構建標簽或者標記被鎖定時，基於標簽或者標記的構建也就確定了。那麼當需要重新構建時，我們就可以基於這些信息重新構建出基線版本。某些時候，標簽或者標記不容易被鎖定，很容易被認為是開發人員刪除了標簽或者標記，然後把另外一個版本的代碼附加到先前的標簽或者標記上。此時，如果構建已經準備發布給QA了，那麼我們就要記錄下當前版本庫的修訂版本。
更改兩行修複缺陷
好的構建工程實踐可以讓你很容易地識別出發布的構建是由哪個版本的代碼生成的。也就是說，看一眼生產環境下正在運行的可執行文件，就可以確定是哪個版本的代碼生成的這個發布。如果堅持遵循這一最佳實踐，修複缺陷時就可以隨時創建一個沙箱(sandbox)，然後從代碼基線獲取正確的版本，更改兩行就可以解決了。
在遇到頭文件版本錯誤或一些編譯依賴問題時就可以確定根本不需要代碼回滾， 改兩行代碼就可以修複。這種做法十分方便和高效。
2.3.4 管理編譯依賴
很多構建失敗都是由於環境問題造成的。比如某個環境變量是用某開發人員的賬號設置的，而兩個月過後準備發布代碼時，在正式環境下用其他賬戶構建時就會失敗。不僅僅是源代碼，所有的編譯和運行時依賴都必須被了解且受控。這就意味著每次構建時，構建腳本必須設置所有的環境變量，以確保所有的構建依賴都是正確的。
2.3.5 獨立構建
避免出現嚴重錯誤的辦法之一就是獨立構建每個發布版本，並且每次構建都是從頂級到下級，所有配置項都重新構建。這通常由一個獨立的版本發布管理團隊完成，或者由持續集成中的自動構建過程完成。許多規章製度不但明確要求職責分離，而且要求有獨立的構建、打包和發布控製過程。看起來好像有很多工作，但是從合規的角度來說，這是一個最基本的要求，大多數金融服務公司、國防部門、醫療部門和政府機構都有這樣的要求。曾經有一個研發經理實施了我的最佳實踐後，很快地就建立沙箱，獲取基線，快速修複問題並部署到生產環境中。他對這種做法非常高興和興奮，以前需要很多時間才能解決的問題，通過實施適當的IT控製就可以迅速做出反應。我們將會在第13章詳細討論限製訪問生產環境。本書後麵還會提到一些其他提高生產效率和質量的實踐。
最後更新：2017-06-05 10:01:45