嗨! 我是Na’Tosha. 我是Unity科技公司的軟體版本與架構開發師(Build and Infrastructure Developer), 那次在Unite 2011會議間與會者聊天,有很多人問我能不能寫一篇關於於Unity公司內部怎樣管理Unity的研發, 版本與測試, 這樣的文章.
基本上我們用到以下類型的軟體:
- Continuous Integration
- Automated Testing
- Code Hosting
- Code Reviews
- Manual Testing
這邊我會談到我們如何用前面四項
持續整合伺服器
我們的版本與自動測試都是靠TeamCity在跑
我們用JetBrains公司的TeamCity, 作為持續整合的方案. TeamCity裡面我們最喜歡的功能是它有很清楚的UI介面, 很明白地指出專案目前的狀態. 關於測試軟體, 我們可以一眼就看出測試是否通過考驗, 以及哪邊測試出現錯誤. 這套軟體可以群體建版(farm builds)並測試, 在Windows, OS X, 與 Linux這些平台上, 並且, 保留過去的版本與測試資料, 這對於知道哪的測試出錯很有幫助. 整體來說, 我們對JetBrains公司提供的軟體功能與支援很滿意!
唯一的抱怨是web UI 這個介面有時候載入很慢, 還有要管理多個分支的專案也會很困難. 因為目前來說沒有辦法對分支之間互為副本(copies of each other)的進行同步化. 儘管如此, 專案還是存成XML, 而且整個架構不會很複雜, 因此, 我自己寫了工具, 直接修改XML檔案.
TeamCity的群體建版(farms builds) ,可以透過40-50台電腦進行網路建版. 有了TeamCity, 我們建構了一個約有45台電腦的網路建版(build farm) 或是稱為建版代理員(build agents). 這裡面有很多是虛擬機器, 執行Windows, Mac OS X, 與 Linux .我們也有一些實體電腦, 用在圖形測試. 因為測試畫面的功能需要GPU層級的調校, 不能用虛擬機器達成. 我們是用VMWare Workstation來虛擬化 虛擬代理員, 在Linux平台,上 使用的是蘋果與非蘋果混合的硬體在跑.
為什麼我們要用虛擬機器呢? 儘管效能上會比較差, 虛擬化讓我們更容易管理系統, 不需要個別升級45台機器. 我們對於某作業系統, 只需要更新模版虛擬機器, 然後複製到執行的版本伺服器(live buildservers)上面. 這樣讓我們可以讓每個代理員都有相同的硬體, 即便它們實際上是在不同的硬體上面跑. 這很重要, 因為當我們添加更多的建版代理員, 它們會在不同世代的硬體上面跑, 從測試的角度來看, 我們需要代理員在相同世代的硬體上面做測試.
自動測試
TeamCity提供了非常清楚的介面, 讓你看到目前測試的狀態
我們有很多不同的自動測試套件, 定期執行. 這些自動測試, 另外也會合併一些手動測試, 用來測量我們的主程式碼穩定度到底怎樣.也會看看寫出的新功能分支是不是夠穩定到可以合併到主程式架構上. 目前有四套測試套件.
- Unit Tests 這個用來測試個別功能/程式碼的小功能的正確性, 但是不會拿來做高階的功能測試. 這是給開發者所用的, 但不是給持續整合伺服器所用.
- 圖形測試, 這個測試會建構一個Unity專案, 對一組的靜態場景做算圖, 專案接著就會在指定的平台上跑 (桌機, 遊戲機或是手持裝置.) 每個場景也都會儲存快照畫面, 我們會比較這些快照畫面跟我們認為是好的畫面作為對照, 如果測試畫面跟標準畫面差到某種程度時, 我們就視為這個圖形測試失敗了.
- 功能測試, 這個測試會執行編輯器或是播放器, 測試不同的功能.
- 整合測試, 這是高階測試, 這個測試會執行編輯器或是播放器, 測試特定或是一組的動作, 關閉編輯器或是播放器, 然後接著下一個測試. 我們的整合測試是用持續整合伺服器NUnit來測試. TeamCity可以直接執行MSBuild專案, 我們有個腳本, 可以讓Mono的Xbuild在Mac OS X上面跑. 我們也開發自己的圖形測試架構.
我們的regression rig會告訴我們是否在播放前一個記錄的內容有任何改變. 我們也有自己開發的regression rig, 類似於圖形測試, 比較之前版本的Unity播放內容, 檢查回歸問題(regressions) .這個是用來找到高階回歸的好辦法. 我們用的測試套件經常都會擴充功能, 跟我們自己的regression rig一起使用, 這樣讓我們找到不少回歸問題與臭蟲.
編碼存放與復審(Code Hosting and Reviews)
如許多軟體公司一般 Unity科技用了很多不同的版本控制軟體, 一開始的時候, 並沒用版本控制, 最後, 第一個Unity Ninjas開始使用CVS 最後使用Subversion. 而一年前, 我們開始研究分散式的版本控制系統. 最後採用的是Mercurial. 現在我們所有的原始碼的版本都在Mercurial. 除了我們公開的Mono, MonoDevelop以及在GitHub 上Boo相關的檔案.
為何要用Mercurial?
嗯, 因為我們有幾項需求: 第一是, 版本控制系統能與我們持續整合伺服器一起運作, 也就是TeamCity. 所以一開始的時候我們考慮了Git, Mercurial, 與 Bazaar, 和Perforce. 我們也想要有分散式的功能, 因為我們有很多不同開發者在不同地點開發, 我們還需要能在多平台上面開發, 分散式的系統讓我們在全球各地的開發者透過遠端的伺服器互動, 也允許我們大家很容易地測試多個本地端的機器的改變, 而不會分享改變所帶來的風險. 我們還希望以分支的方式進行功能開發, 然後之後再合併到主程式裡面. 於是最後剩下Git, Mercurial,與 Bazaar做篩選了! 我們花了點間評估這些軟體, 專注於:
- 我們想要一套簡單的, 容易使用與理解的command-line介面
- 好的 GUI工具, 可以用在OS X 和Windows平台上面
- 也要能有好的程式碼檢視工具
我們也想要這個軟體能提供我們動能, 這個軟體本身要能成長與改進, 在幾週的測試之後, 我們最後選擇了Mercurial, 因為:
- 跟Git比較起來, 十分簡單容易學
- 不論是Windows或是Mac都有好的GUI工具
- 有很多選項, 關於大尺度的程式碼檢視工具
- 有很多人用, 軟體也經常更新. 對於開放式的專案或是商業專案都適用
- Mercurial最大優勢是, 它是唯一的DVCS, 能夠用來處理大型binaries資料, 這可以透過針對Mercurial的開放式延伸功能來進行.
分散式的版本控制系統 ,本質上, 對大量的binaries處理不會很好. 因此, 我們知道我們需要夠與版本控制的系統結合, 來儲存大量的binaries. 但某種程度上讓我們進行版本控制, 不必讓我們從零開始寫自己的系統, 這樣很棒!
如何建構Mercurial? 而程式碼檢視人員可以拿這個做什麼?
在決定使用Mercurial之後, 我們需要找到如何導入Mercurial 要怎樣拿來檢視編碼. 有了這套, 我們還想要建立新的開發政策, 到目前為止, 我們只寫單一的編碼庫, 除非為了新版才會有分支, 這樣的流程會導致常常會程式爛掉, 對生產力有嚴重不良影響. 我們希望能輕易地產生版本分支, 然後再把分支合併到主幹上面, 這樣讓程式主幹盡可能地維持在穩定狀態.
用Kiln進行程式碼檢視
我們找了幾個不同的程式碼檢視系統, 最後採用的是Fog Creek Software公司所推出的Kiln. 很多人已經知道了我們用FogBugz作為錯誤追蹤系統(issue tracking system), 由於FogBugz還有改善的空間, 而這套軟體用起來也很不錯, 最後我們有大量的資料在這個系統裡面. 這樣, 我們有很多理由來把資料搬到新系統. Kiln是一套Mercurial code hosting系統, 程式碼檢視是依據per-changeset為基礎的, 以及伺服器端的Mercurial延伸功能安裝能夠處理大量的binaries. 我們在用Kiln遇到一些狀況, 大部分是跟效能有關. 目前的儲藏資料大小是1.6 GB. 裡面有乾淨的運作版本, 以及很大量的binaries, 加上好幾個同時進行的開發者有 65人, 而且還在成長, 我們的版本農場(build farm) 45台機器, 似乎已經把效能逼到極限了.
self-hosted版本的Kiln, 目前並沒有想用來用在大型團隊, 因為會導致非常慢的clones & pushes. 希望啦, 這些問題在將來能解決. 我們不確定將來還會用Kiln, 但是我會說目前的功能相當不錯, 它允許我們以分支的方式搬移功能專案, 而不是用主幹線的方式. 請注意, 這軟體是用.NET所寫, 也不能在Mono上面跑. 所以如果你想要用Kiln, 你就必須要有Windows伺服器. 我能說的是Fog Creek的支援團隊花了很多時間, 幫我們處理Kiln的許多問題.
結論
對這麼多不同平台進行建版與測試, 真的很困難, 特別是我們開發團隊還一直在擴編, 我們發現在基礎設施的處理領域超出原本預期, 這些工具對於開發團隊很基本, 是我們這邊開發Unity會用到的工具.
Unity 3D台灣代理請洽 奇銳科技 (02)2557-3321
沒有留言:
張貼留言