只有版本控制軟體,仍然不足夠
昨天在Plurk與同人討論一個最近遇到的問題, 為何現在還有公司在使用Visual Source Safe? 同人的一句話倒是將我點醒了
同人:站在開發者的立場，我認為這不是主要問題，而是最需要解決SCM的問題是什麼?
由於公司代理的codeBeamer產品, 其最大特色就是與版本控制軟體軟體做整合, 所以經常會遇到客戶來詢問版本控制軟體的相關問題?或是codeBeamer跟版本控制軟體整合有什麼好處? 所以我有一部分的時間都在回答這方面的問題, 但也因為這樣, 讓我容易陷入工具與技術的漩渦, 而忘記了問題背後的問題.
使用版本控制軟體要解決什麼樣的問題? 這個問題的反面是版本控制軟體沒有解決那些問題?
這個問題的重要性遠比你要選擇什麼樣的版本控制軟體來的重要, 但是確被你我忽略了, 了解了這個問題後再來選擇工具, 你會更清楚你的團隊適合什麼樣的版本控制工具而不會人云亦云, 陷入選邊站的迷思.
為了找尋以上的答案, 我們先從版本控制在維基百科的定義
繁體中文 版本控制
簡體中文 版本控制
維基百科很清楚的定義版本控制的用途, 並完整的描述了版本控制有那些模型, 例如Merge ,Lock 等等, 還有版本控制常用的專有名詞例如Baselines,labels,tags等等,所以透過維基百科的解釋, 我們可以很清楚的了解版本控制簡而言之主要幫我們管理與記錄檔案的變動, 並讓團隊的參與者可以重現或是取得一致性的檔案. 但是維基百科的條目並沒有解釋 版本控制軟體沒有解決那些問題?
在找尋這個答案之前, 我想先釐清一些名詞, 至少以我而言, 這些名詞困擾了我一陣子
1. SCM (source code management)請參考 Revision Control
2. SCM (Software configuration management)
In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software
3. CM (Configuration management)
Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.
從以上三個維基百科的條目解釋, 你會發現原來一般顧問口中的SCM有兩種意涵, 而且SCM不等於CM , 我建議如果在指source code management應該用VCS(Version control system )比較好. 至於CM(Configuration management) 與 SCM (Software configuration management) 差別在那裡? 簡而言之, 範疇的範圍不同, CM含括了SCM, SCM只是CM的一小部分. 舉個例子來說
一台電腦的組成有主機板, BIOS, OS, 鍵盤等, 這時候CM對你的開發團隊就相對的重要, 當主機板+BIOS+OS+鍵盤, 當主機板換了一個零件, 會不會造成BIOS無法work ?? BIOS無法work, 會不會造成OS無法work?所以CM在產品工程與系統工程是很重要的概念, 而SCM只涵蓋到了軟體工程的變更管理.
了解這三種名詞的差異性, 可以知道版本控制軟體只解決了檔案變動的問題. 但確無法追蹤這些檔案的變動與軟體的變更或是臭蟲(Bug)甚至系統的規格變更有什麼關係? 舉個例來說, 一般的版本控制的軟體都有支援Tag/Label的功能雖然你我都知道當軟體要Release時要做Tag與Label , 而且在做Tag與Label同時也會描述與記錄這個Tag/Label , 但是我們還是無法得知, 這個Tag/Label所Build出來的軟體解決了那些Change Request/Bug(or Release Note)?這也是目前市面上所有VCS軟體的限制. 為什麼Tag/Label要能與記錄Change Request/Bug的資訊系統做關連? 如果Label與Tag的用意在讓Developer可以重現當時的release版本, 那麼這個關連性除了可以讓專案經理清楚知道這個Label/Tag存在的原因, 也可以讓Developer去review是否目前release的版本中的bug, 是由這些關連的Change request所產生, 並可快速找到問題的癥結.
結語:
當我們去了解VCS可以做什麼, 不可以做什麼, 接下來再來思考使用什麼VCS工具以讓團隊的工作更順暢, 就更有意義了.
留言