OpenBSD 開發與版本控管流程

要如何做才能真正在每次版本發行時，能夠不再因為重大軟體瑕疵
而延遲、改變時程？

OpenBSD 的開發流程，告訴我們的是開發流程與軟體品質的密切關
係，OpenBSD 團隊如何克服開發、測試時人性懶惰的弱點？以及他
們考量哪些重點？做了什麼？80 位開發成員如何互動來確保軟體品
質。

首先是對發行版本這項工程的定義：用科學方法設計、開發結構、
機械、裝置或製造過程；不論是處理個別單一項工作，或是整合成
一體的工作；也是對於建構、操作有完整認知的過程；在特定控制
變因內預測行為；所有針對特定功能、經濟運作、保全生命財產安
全等都算是工程的定義。

一般商業公司有足夠的人力、資金、時間可以同時有開發、測試團
隊一起運作，但是開放源碼軟體在這種執行模式下會有問題...發行
的軟體版本通常是未經完整測試的產品，需要持續修正。

發行版本的理想程序是：全部程式碼都經過測試、經過最多人測試
、最短的測試時間、最少的痛苦除錯...當然實際上我們只能取到折
衷方案。

完美的發行理想程序可以帶給我們：沒有重大錯誤造成使用者退回
上一版、大部份的新開發功能都可正常使用、開發者開心、使用者
歡喜、可以在發行版本後快速回到功能開發。

但實際上常是發行版本後，進入維護版本的除錯無間地獄...

最常見的流程就是：開發 --> 準備發行版本放慢開發腳步 -->
Tag/branch release tree --> Test & Fix --> Product N
通常是在 branch 之後交由發行版本的團隊進行 build/test，然後發
現錯誤需要 bug fix merge 回 trunk，或需要由 trunk merge 到發
行的 branch，就一直循環....直到真正修完錯誤，或是大家都精疲力
盡，結果通常是：好吧，只能出這版了！

其中的問題點在於：
一、只有少數人在測試
二、開發者在要發行版本的 branch 除錯修改程式
三、發行後的重點變成維護產品 branch
四、流程容易拖延
五、許多開發者陣亡(指對這個產品的心靈已死)

OpenBSD 進入 Tag/branch 之前的開發流程：

減慢開發速度，進行回歸測試-->鎖定 API/ABI 不再變更-->
早期套件 build test -->鎖定 tree(需經認可後才能再更動)-->
開發者執行測試工作-->Tag/Branch-->解除鎖定-->修改細項-->
正常開發步調-->重大更新-->六月個的開發週期-->減慢開發速度

1.
其中的發行版本修改，都只需要做到微調的動作。並且我們會使
用自己的產品來進行開發(Eat our own dog food)。

2.
鎖定 API/ABI 的原因：此時上層軟體套件才可以編譯，並可同時
發現影響版本發行的重大議題。每天都會編譯程式碼。Daily snapshot.
在編譯軟體套件時發現的回歸測試錯誤，在此時就已經開始修正。
修正完畢後才進行 tag/branch, 接著 unlock 後就可以回到 mainline
持續開發。

3.
鎖定的動作是不預警的，因為人們容易忽略行事曆中的例行事項，
針對測試週期的結果，降低過多錯誤的開發者修改程式的權利。

4.
所有工程師都會參與發行版本時的每一步流程。這可以避免短缺的
測試人力。

5.
作者也承認是因為 OpenBSD 的管理作風比較接近獨裁(theo)，因
此其他開放源碼專案可能無法直接套用這個方法，但是對於軟體開
發公司就相當有用了。

相關連結：

The OpenBSD release process, A success story