從iPhone 3.0.1更新看軟體版本控管策略1/2
Apple在8/1開放下載iPhone 3.0.1, 這個更新主要為了解決這個安全漏洞, 我在7/31看到這則新聞, 在8/1看到下載更新的消息, Apple對於安全漏洞的危機處理果然令人激賞(註A) 我昨天看到這個更新, 讓我想起一些我一直想寫的關於版本控制的教育訓練文章, 我想這次的iPhone更新剛好是一個版本控制演練.
**請讀者耐心讀下去, 除了這次iPhone 3.0.1的案例, 在下一篇文章,我還要講一堂價值NT 2000萬的真實案例.
如果有跟Apple購買iPhone Developer Program的網友早已知道 Apple在Release iPhone 3.0沒多久, 就開放讓Developer下載iPhone 3.1 beta SDK, 所以過不了多久, Apple等到iPhone 3.1 beta測試了差不多, 就會Release iPhone 3.1版. 但8/1 Apple為了修正安全漏洞, 很快的推出iPhone 3.0.1版, 所以, 聰明的你可以看出, Apple iPhone開發團隊一定維護了兩個iPhone OS版本, 一個是iPhone 3.0 , 一個是iPhone 3.1 , 在iPhone 3.1 Final版還沒穩定之前, 還可以Release iPhone 3.0的修正版就可以了. 這個道理看似簡單, 但是還是會有網友會問, 為什麼要這麼麻煩?? iPhone OS 3.0 release後, 開發團隊不就火力全開, 努力往iPhone OS 3.1前進, 而且iPhone OS 3.1已經到了beta 3, 應該差不多了可以release了, 為什麼不趕快release 3.1 final版來解決這個安全漏洞, 一來節省RD的開發時間, 一來兼顧消費者的期待, 但是軟體開發不如意十之八九. Apple會這麼做, 原因可歸納如下
iPhone 3.0從3月起, 開始從beta版開放測試, 期間已經經歷大約4個月才release final版, 除了4個月的beta版公開測試,在beta版之前,Apple內部應該也測試了幾個月, 以這樣長時間的測試,iPhone 3.0新增的許多新的功能應該通過所有unit test/test case測試. iPhone 3.0算是一個stable的版本 ( 也許你不同意iPhone 3.0 == stable, 這我可以理解), 針對iPhone 3.0修正的安全漏洞的source code其相依性(dependency) 遠比針對從iPhone 3.1開始新增/修改的code其相依性來的少很多, source code修改相依性少, 加上之前長期的測試Apple SQA人員, 自然有把握可以在這麼短的時間完成iPhone 3.0.1測試, 並release給使用者upgrade. 簡而言之, 所以將iPhone 3.1 beta3 修改後release給使用者其風險遠高於iPhone 3.0.1
我想Apple內部應該有更精確的測試數據.
這裏我要稍微解釋所謂的相依性(dependency) , 軟體是由許多模組所組成, 如果你開發一個模組A,剛好被模組B,模組C所使用, 這樣你可以說模組B,C與模組A相依, 如果軟體發生了一個Bug, 這個Bug
剛好要去修改模組A, 那麼很有可能模組A的Bug解決了, 卻造成模組B與C的功能不正常, 所以在軟體開發過程, 模組A,B,C都會開發許多的unit test, 這些unit test會在build過程中去執行, 已確保修改source code確造成其他相依的模組無法work
所以有了這個iPhone 3.0.1的案例, 如果你的軟體開發團隊也面臨類似的問題. 而且團隊也在使用版本控制軟體(SCM)例如,VSS,CVS,SubVersion,Git,Mercurial等等, 那麼你會怎麼做?
1. 善用版本控制軟體(SCM)工具的tag功能, 在每一次的release都在做tag(標籤), 這樣才能完整的將stable release的source code checkout來做branch
2. 善用版本控制軟體(SCM)工具的branch功能, 當軟體要進行下一版的修改, 最好是在另一個branch中進行
以下兩種SCM的Pattern模式, 都可以應付當下一版軟體還沒stable, 而要先修改stable版的bug且需要在短期內release的狀況.
留言
謝謝你的指正, 我是7/31才知道有這個漏洞, 看起來我的資訊管道太慢了