顯示具有 全員測試 標籤的文章。 顯示所有文章
顯示具有 全員測試 標籤的文章。 顯示所有文章

2010年6月6日 星期日

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