每個經曆過完整遊戲項目開發的人都永遠會清楚的記得從開發到運營階段所經曆過的那些痛苦:枯燥的代碼提交、代碼更新、編譯、提交可執行程式再到測試的過程;永遠改不完的BUG;修改了一處BUG結果引入了更多的BUG;添加了一點新功能導致原來的功能不能用;每次更新新版本前的戰戰兢兢,等等等等。
有人說技術的進步是為了懶人們的功能,也確實,當我們不想再去做那些繁瑣的工作時,我們便有了這些方便的自動化工具:比如我們會自己寫一個批次檔用來自動化的提交、更新代碼,調用編譯器進行編譯,然後把編譯的結果拷貝到一個指定的目錄。我相信大部分人的程式生涯中都會編寫過這樣一些批處理指令碼,或者使用過類似的指令碼,當然,也有可能我們會把這些指令碼做的更加可視化一些,比如再加一個漂亮的GUI介面,事實上我以前所參與的項目也曾經做過這些事。
而對於BUG的問題,也有了更加成熟的解決方案,比如單元測試,系統測試方法論,以及相關的測試載入器與架構代碼,如CPPUNIT等。
如果你正開始一個新的項目,也許你會有原來已經完成過的類似指令碼拿來使用,或者你也有可能會安排一兩個人手來開發一個新的自動編譯工具,當然,你可以選擇的一個更好的方案是使用一個現成的開源解決方案。使用開源社區提供的工具已經不是什麼新鮮事了,在自動構建領域也有這樣一個非常好的工具,叫做Cruise Control。
關於如何寫CC的設定檔config.xml就不需要多說了,CC內建的document是最好的資料,看完自然就明白。當然,事實上我在做配置實驗時也碰到了些困擾,最後是求助於google才得以解決,如果不幸你也遇到了類似的問題,比如不論怎樣嘗試,CC都不能正確的從SVN的倉庫checkout代碼,那麼你可以看看這裡
http://www.oracle.com/technology/products/jdev/tips/mills/cruisecontrol/jdev_svn_cc.html
其實就是Ant的SVN Task做的還不夠完善,所以有人重新做了一個,並且增加了很多有用的功能,可以協助我們實現更多的自動化任務。
另外一點就是CC的publisher了,CC本身也內建了多種發布方式,包括通過ftp上傳,發布郵件通知等等,但實際上據我個人的觀察,讓每個程式員主動地去檢查郵件或者查看某個網頁是件不太容易辦到的事,程式員們總會有各種各樣聽起來似乎非常合理的借口來說明為什麼沒有及時地去查看編譯結果,就算是Notes附帶的強大的通知程式也沒有多少人願意開。所以,必須有一種更加直接的方法來通知開發人員編譯結果。
我們曾嘗試了一種方法,把編譯結果通過程式員們最常用的IM工具發送給他們。雖然程式員們不大善於口頭交流,但是對於聊天工具卻大都相當的鐘愛,所以在這裡將結果發給他們,他們是沒有理由不去關注的。
然後就是自動化測試。我覺得完全的自動化測試過程只能在單元測試這一級,要想實現完整的系統測試與整合測試不太容易,尤其對於我所參與的網路遊戲這一類項目來說,所以我也只要求了這個自動化Integration Environment裡實現單元測試這一步。其實保證了各單元模組的功能正確,系統的bug數量就已減少了一大半。
測試的架構也比較多,從老牌的CPPUNIT到新近推出的google test frameworks,按照程式員們自己的喜好自由選擇一款,最終也是通過Ant的外部Task整合到CC中。
最後是版本的發布。如果參與過遊戲項目的完整運營,那一定知道遊戲正式上線的版本會比較多,比較亂,如何管理好這些不同的版本就是我們的自動化Integration Environment可以完成的工作。比如一般會有一個正常版本,還會有一個增加了部分測試功能的外網測試版本,再加上一些為特定的伺服器定製的活動,為特定的伺服器修改了數值的版本,等等等等。到後面伺服器維護時,經常會頭疼於這些版本的管理,以及每個版本對應的pdb及map檔案的管理。
如果能有一種自動化的方案幫我們將這多種版本自動產生,自動分類,自動歸檔,那將會是一件讓人省下不少心的大好事。事實上,只要我們做好了配置,CC確實可以幫我們完成這繁瑣的工作。
說完了自動編譯,那就該方說說持續整合了。其實把上面說的這些工作加起來就構成了持續整合的工作,只是這些工作需要不斷的去完成,當然也是通過機器自動來完成,不是手工的一項項去做。
持續整合通俗的說就是持續地,頻繁地進行整合,每當有新的修改加入的時候,修改的作者能夠被及時的告知他的修改是否在加入新功能的同時保證原有功能的完整。
還是用CC來說明持續整合的過程吧。另外CC雖然是用Java語言編寫的,但這並不表示CC只能用來做Java項目的整合管理,C++一樣可以。可以讓CC定時地從SVN倉庫中update最新的代碼,然後調用Ant的外部命令,執行make或msbuild來編譯工程,然後再調用cppunit架構來進行單元測試,接著把編譯及測試結果發送到IM工具上,最後把編譯的可執行檔發布到指定目錄,歸檔。
CC其實就像一個總指揮,由它來調度外面的工作,比如自動編譯,自動化的測試,自動發布等。而外部的每一項工作都可以自由定義,當然我們大部分都是採用的Ant來完成,因為Ant已做的足夠強大。
最後想說的是,工具再強大還得要看如何去使用它。比如是不是將持續整合落到了實處,不是一個只給老闆看的花架子;自動化單元測試是不是按照最初的設想在實現,程式員們有沒有按照要求為每個模組每個介面編寫測試案例並添加到測試架構中,等等,這都需要專案管理者來推動並監督。
雖然一開始這個過程可能會與原來的那個過程一樣令人不大愉快,但是當走上正軌以後,一定會給整個開發過程帶來相當大的益處。