MaoYang-有話要說

昨天在Plurk與 同人 討論一個最近遇到的問題, 為何現在還有公司在使用Visual Source Safe? 同人的一句話倒是將我點醒了 同人:站在開發者的立場，我認為這不是主要問題，而是最需要解決SCM的問題是什麼? 由於公司代理的codeBeamer產品, 其最大特色就是與版本控制軟體軟體做整合, 所以經常會遇到客戶來詢問版本控制軟體的相關問題?或是codeBeamer跟版本控制軟體整合有什麼好處? 所以我有一部分的時間都在回答這方面的問題, 但也因為這樣, 讓我容易陷入工具與技術的漩渦, 而忘記了 問題背後的問題 . 使用版本控制軟體要解決什麼樣的問題? 這個問題的反面是版本控制軟體沒有解決那些問題? 這 個問題的重要性遠比你要選擇什麼樣的版本控制軟體來的重要, 但是確被你我忽略了, 了解了這個問題後再來選擇工具, 你會更清楚你的團隊適合什麼樣的版本控制工具而不會人云亦云, 陷入選邊站的迷思. 為了找尋以上的答案, 我們先從版本控制在維基百科的定義 英文 Revision Control 繁體中文 版本控制 簡體中文 版本控制 維基百科很清楚的定義版本控制的用途, 並完整的描述了版本控制有那些模型, 例如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 man

第一次聽到 Hudson 是INTLAND CEO Janos來台灣訪問時所分享的一個Build Server解決方案, 後來又看了這篇文章 當紅炸子雞:Continuous Integration , 更加深對Hudson的印象, 於是心中開始了一個藍圖, 如何將Hudson與codeBeamer整合在一起? 之所以會有這個想法, 有以下原因 1. codeBeamer雖然有內建Build management, 與排程設定, 並與SCM良好整合, 但是還是有所受限, 例如一家公司的軟體專案的Build sandbox可能是不同類型的專案例如Mac/iPhone, Java, Android, .Net, C/C++,Embedded Linux, 這些Build Sandbox並不一定與codeBeamer安裝在同一個Server, 可能是分佈在不同的Server或是VM(virtua l machine) , 所以獨立的Build Server有存在的必要性. 不過codeBeamer內建的Build並不會有獨立的Build Server而失去其重要性. CB內建的Build與內建Report功能已整合, 可以排程來自動產生Excel格式的報表. 2. 如果獨立的Build Server有存在的必要性, 則Build Server最好有以下特性 容易與各式不同的SCM Server(CVS/SVN/Git/Mercurial)做整合, 因為要Build source code前要先從SCM server checkout source code Build Server可以支援各式軟體專案, 如C/C++, Java, .Net ,Mac Cocoa. Build Server容易與外部Server整合, 例如Build失敗要發e-mail通知, Build成功要將build好的檔案deployment到Test server, 或是File Server. Build Server必須支援Windows/Linux/MacOSX Hudson正好符合這些特性, 而且Hudson支援Plugin, 你可以寫Plugin來擴充Hudson, 也可以在Hudson網站找到許多Plugin, 令我興奮的是Hudson支援 Groovy . 為何支援Groovy讓我

Apple在8/1開放下載iPhone 3.0.1, 這個更新主要為了 解決這個安全漏洞 , 我在7/31看到這則新聞, 在8/1看到下載更新的消息, Apple對於安全漏洞的危機處理果然令人激賞(註A) 我昨天看到這個更新, 讓我想起一些我一直想寫的關於版本控制的教育訓練文章, 我想這次的iPhone更新剛好是一個版本控制演練. **請讀者耐心讀下去, 除了這次iPhone 3.0.1的案例, 在下一篇文章, 我還要講一堂價值NT 2000萬的真實案例. 註A: 感謝網友 LFlower 糾正, Apple早在六週前已接獲通知有這個安全漏洞, 請參考 這裡 如果有跟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