軟體開發出來後, 就到整合和發行的流程, 在這階段我提出品質控管,發行頻率和版本規則來討論.
軟體開發出來後, 就到整合和發行的流程, 這邊我想特別提出來的是品質控管,發行頻率和版本規則.

軟體開發過程, 會不斷的發行版本, 如何讓發行出去的版本有一定的品質, 並且讓使用者可以一目了然呢? 早期要發行版本的時候我常遇到 Build code 的時候Build 不過, 或是版本發出去被QA抱怨品質很差或是已經解過的Bug又出現 , 因此後來採用了一些方法來改善這個問題, 提供給大家做參考:
(1) Code review: 改的程式碼要放上SCM的時候, 要先給別人Review過, 另外可指派資深的工程師, 定時的Review SCM 內修改過的程式碼.
(2) 單元測試: 工程師修改的程式碼要放上SCM的時候要先做好單元測試, 確認基本功能都沒問題, 還要不影響別人的功能以及不影響整體系統的耗電量. 當Image Build 出來之後, 也要再做過一次單元測試. (可要求工程師為自己的模組寫好Test Case)
(3) 整合測試: Image Build 出來之後由專人進行整合測試.
(4) 原有Critical Bugs 的測試: 保存一份重要Bug的列表, Image Build 出來後由專人測試確認已經解決的大Bug是否有再發生.
(5) Release Note的整理: Release Note 的整理也很重要, 除了記錄版本資訊外, 本次修改的功能, 已知的Issues, 歷史版本等都要列入, 方便未來參考用.
(6) Daily build: 固定每天Build 一版軟體, 確保工程師每天進的程式碼是沒問題的.
以上幾個措施, 能夠讓發行的軟體的品質大大提升, 不過基本上這些都比較是治標的方法, 提升工程師的能力, 養成良好的習慣才是治本的方法.

剛剛提到了軟體的發行, 又提到了 Daily build. 那麼版本發行的頻率要怎麼抓比較好呢? 對於系統整合廠的軟體而言, 因為產品的週期很短 (約半年, 持續縮短中), 所以一個專案的開發時程也不會太長, 平均而言約 4~5個月, 所以每個硬體版本間隔頂多是1~1.5個月. 在期間軟體必須不斷的修改, 提供給硬體或QA做測試. 因此我建議例行性的Release 大概抓一週一次 (我稱它做Weekly build), 而之前講過幾個軟體重要時程點, 基本功能完成, Feature complete, 每次生產用的版本, Alpha release, Beta release 和正式版的發行, 再從Weekly build 裡面去挑選. 而前面提到的Daily build 則屬於內部的版本, 只在軟體團隊內使用, 不會發行出去.

接著再來談談版本編碼規則, 一般訂定版本時會考慮到的有主次版號, 發行次數, 編譯次數, 正式版測試版或發行候選版. 對系統軟體而言則要多考慮BSP版本以及作業系統版本, 這邊舉個例子給大家, 但未必要按照我的做法去編碼. 我的設計是使用四碼來編號.
第一碼為主板號, 用來區分測試版, Alpha, Beta 和正式板.
第二碼為次版號, 當有 BSP 或是 OS 更新的時候就進一碼.
第三碼為發行次數, 每發行了一版就往上跳一號.
第四碼則為編譯次數, 每次編譯就會往上增加一號. 發行後再歸零.
除了以上考量, 另外還有一個考量的是Daily build 和 Weekly build 的編碼. 我參考了Linux的編碼原則, 把第四碼做個改變. Daily build 採用奇數號, Weekly build 採用偶數號.Daily build 會從 1, 3, 5, 7 去跳號, Weekly build 則由 2, 4, 6 ,8 去跳號. 直到一版Weekly build 發行後, 再歸零. 舉幾個例子如下:
0.2.2.1 : 表示測試版 , 換過一次BSP , 第二週的第一次Daily build.
0.2.2.4 : 表示測試版 , 換過一次BSP , 第二週的Weekly build, Biuld 了兩次才成功.
註:Linux kernel 3.0之後採用了新規則, 我覺得新的規則也蠻適用的, 也許將來我會改用.

最後我把軟體發行的流程大概整理如下:
(1) Daily build : 工程師改Code -> review Code -> lock SCM -> 編版本 ->build code -> 工程師驗證 -> unlock SCM
(2) Weekly build: 工程師改Code -> review code -> 通知要Build code -> lock SCM -> 編版本 -> build code -> 驗證可開機 -> 發信請大家做單元測試 -> 工程師驗證 -> 做整合測試, Critial bugs 測試 -> 製做Release Note -> 發行版本 -> unlock SCM

整個流程如果中間有驗證發現問題, 就得重頭開始跑. 所以算是蠻繁瑣的過程. 因此建議能夠把整個流程儘量都交給電腦做 (人腦雖比電腦聰明, 但人比較容易出錯, 所以複雜但重複性的工作就儘量將它自動化). 你只要將 SCM 軟體, 專案管理軟體, 檔案庫, Mail Server 等系統整合, 就可以將整個流程自動化 . 目前我可以做到除了工程師改Code, 做驗證這些一定是人工程序外, 其它的流程都可以自動化了. 詳細做法留待後面的章節再說明.