2009/4/1

開放軟體社群專案 - 開發模式簡介, 工具名詞解釋


Neng-Yu Tu (Tony Tu)

拜微軟良好的 MSDN 及產業的 ecosystem 建立完整之賜, 加上超級強力的 IDE Virtual Studio. 一般習慣 "微軟" 開發人員進入到 Open source 環境的時候, 由於工具跟說明都是散在各個地方, 最大的問題是被一堆新名詞/新指令搞的頭昏腦脹, 或是不太清楚工具的功能或使用方式. 下面是一些常用開發名詞, 開發流程, 跟工具功能

簡單的解釋.

名詞-
* Autotools: 如果想讓你的程式能夠在各個不同平台下編譯, autotools is the ABC have to follow.
* Toolchain: 編譯跨平台程式需要編譯器組合 (for example: x86 base to ARM base)
* OE: OpenEmbedded 的縮寫, 透過 OE 提供的套件庫, 你可以編譯不同硬體架構平台相關的整個 rootfs 所需要的檔案.
* Bitbake: OE 使用編譯套件庫的 make. 一般編譯器透過 config 編譯出所需程式, bitbake 透過 receipt 編譯特定平台上的所需的: 單一套件, 多個套件, 或整個 rootfs image, 同時可協助處理相依性的問題.
* Monotone/git: OE 使用的版本管理平台, 以前是 monotone, 現在開始改為 git (git 最早也是根據 monotone 改寫), 透過各種 manifest (檔案的清單, 套件的清單, 清單的清單) 做為所有套件版本追蹤的根據.

我把 monotone/autotools/OE 相關的 usermanual 放在 http://t0ny.net/openmoko/doc/ , 最新的, 可以到 http://www.openembedded.org/ , http://monotone.ca/ http://bitbake.berlios.de/manual/ 下載. git 相關的可以很容易從網路搜尋到.

開發流程-

其實軟體的開發流程並不應該是有區分開放軟體, 或是一般軟體的差別. 現實生活中, 開發方式也跟組織方式和人力調配方式有關. 但是大型 "開放" 軟體專案, 因為可能 90% 以上的軟體元件或函式庫並不是由自己開發, 如果不想要自己管理每一個組件的版本及設計細節, 只有藉助像是 OpenEmbedded 的平台來提供相關的組件原料.

一般的商用 embedded system 套件, 大部分都是已經 freeze 裡面所有套件的版本. 有問題或功能增加時, RD 只需要更新裡面的少數套件. Windows Embedded 是這種方式的典型代表. 其他像是 MontaVista 也是類似的方式.

但是 Linux 及較不純的 Android, 因為加入了社群開發, 所以套件的修正其實是很頻繁的. 套件間又有相依性的問題, 所以要能夠自己 download source/patch, 及 daily build 的能力其實很重要. 要能Daily build 所有變更中的專案 source, 其實很麻煩 (簡直是惡夢), 所以需要 OE 這類平台及 bitbake 這類工具幫助. 當然, release 產品並不一定需要所有的 package 都是最新的, 除非是因為有某個開發模組的相依專案, 也一直在更新. 相對於傳統開發, 就等於是有多個不同小組同時開發一個大型專案. 但這種開發方式, 對於本身就是分散式開發的 Linux 是非常常見的狀況.

所以, 透過 OE (組織) 的 monotone/git (版本管理工具) 及 bitbake (編譯選擇工具) 及 bitbake 的 receipt (編譯條件實際內容清單) 來做版本管理. 通常 Open source 專案的 binary download 網站會有幾個目錄 包含專案不同階段的 binary 及 package:

* stable: 穩定版, 或是經過測試的 release 版
* testing: 開發版, 或是正在測試中的版本
* unstable: 直接 daily build 出來, 或是未經測試的版本

如果要 sync 不同小組的工作, 每個小組都必須熟悉相同的工具, 在 linux 社群中, 因為所有的大型開發都是分散式, 所以需要不停的 sync (daily build/daily update), 使用相同 source, 才能整合不同團隊間的工作及合作.

開放軟體的開發, 通常最大的難關並不是技術或是工具的使用上. 而是讓開發人員習慣將程式碼, 每天或是每個問題有初步解決成果後, 就提交到 mailing list 中討論. 而不是悶著頭把程式寫到非常完整, 或是非常複雜才提交. 因為在開放環境下, 每一個人都可能在作同一份工作, 遇到相同的 bug. 唯一有效率的方式是當解決問題後, 盡快的提交 mailing list 或 maintainer 審核. 避免其他人也在解一樣的問題. 因為一旦 fork 太久, 任何人寫的程式都很難再與其他人程式整合.

大部分我目前遇到的 opensource developer, 例如 (harald/werner/andy...) 等, 他們解完問題到提交的時間不會多於 24 小時. 並不是在短短時間內, 他們提交的 code 一定不會有問題. 而是專案進行的模式, 就是 relaese early, release often.

沒有留言:

 
Creative Commons License
著作 係採用創用 CC 姓名標示-非商業性-相同方式分享 3.0 台灣 授權條款授權.