Hudson+Continuous Integration筆記1
第一次聽到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(virtual machine) , 所以獨立的Build Server有存在的必要性. 不過codeBeamer內建的Build並不會有獨立的Build Server而失去其重要性. CB內建的Build與內建Report功能已整合, 可以排程來自動產生Excel格式的報表.
2. 如果獨立的Build Server有存在的必要性, 則Build Server最好有以下特性
Hudson正好符合這些特性, 而且Hudson支援Plugin, 你可以寫Plugin來擴充Hudson, 也可以在Hudson網站找到許多Plugin, 令我興奮的是Hudson支援Groovy. 為何支援Groovy讓我如此興奮? 可以參考我之前寫的一篇文章使用codeBeamer+Groovy script+Build-以Scrum專案管理為範例 , codeBeamer+Groovy+Hudson等於是完成長久以來我心中一直無法完成的一個拼圖-->獨立的Build Server無法與codeBeamer做互動.
以下這個架構圖可以更進一步解釋這三者整合起來, 也可以看出對Continuous Integration有何妙用.
這個架構的啟發, 主要來自O.David的簡報http://www.javaforge.com/displayDocument/BPM.pdf?doc_id=68991, 其中他談到所謂的
Auditable Build Management
以往我認為Continuous Integration中的Daily Build, 只要去排程讓Server自動去執行Build就好, 但是O.David則更深入, 他利用了Groovy與codeBeamer api整合創造所謂的Auditable Build Management. 也就是Daily build不再是無條件的build , 而是當當日CB Server中有發現Bug狀態是Fixed or Task狀態是Implemented 且這些Bug與Task都有對應的scm commit訊息, 則Build source code 的條件才成立, 並且Build成功後, 會自動在codeBeamer建立一個MileStone,且將build log, build完成的檔案, 和觸發這個build的相關issues關連在一起. 你可以想像, 當一個開發專案, 每天都有超過10個以上的issue, task被解決並要Build後驗證這些解決的issue, 如果能把其中一些瑣碎的事交由script來自動執行, 這樣Continuous Integration是不是更有效率一些?
附註: O. David在他的簡報並沒有提到unit test, 可能是每個專案的unit test框架不太一樣, 例如Java使用JUnit, .Net使用NUnit, Cocoa使用OCTest,所以他略過了. unit test可以在build script中設定理論上是沒問題的.
1. codeBeamer雖然有內建Build management, 與排程設定, 並與SCM良好整合, 但是還是有所受限, 例如一家公司的軟體專案的Build sandbox可能是不同類型的專案例如Mac/iPhone, Java, Android, .Net, C/C++,Embedded Linux, 這些Build Sandbox並不一定與codeBeamer安裝在同一個Server, 可能是分佈在不同的Server或是VM(virtual 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讓我如此興奮? 可以參考我之前寫的一篇文章使用codeBeamer+Groovy script+Build-以Scrum專案管理為範例 , codeBeamer+Groovy+Hudson等於是完成長久以來我心中一直無法完成的一個拼圖-->獨立的Build Server無法與codeBeamer做互動.
以下這個架構圖可以更進一步解釋這三者整合起來, 也可以看出對Continuous Integration有何妙用.
這個架構的啟發, 主要來自O.David的簡報http://www.javaforge.com/displayDocument/BPM.pdf?doc_id=68991, 其中他談到所謂的
Auditable Build Management
以往我認為Continuous Integration中的Daily Build, 只要去排程讓Server自動去執行Build就好, 但是O.David則更深入, 他利用了Groovy與codeBeamer api整合創造所謂的Auditable Build Management. 也就是Daily build不再是無條件的build , 而是當當日CB Server中有發現Bug狀態是Fixed or Task狀態是Implemented 且這些Bug與Task都有對應的scm commit訊息, 則Build source code 的條件才成立, 並且Build成功後, 會自動在codeBeamer建立一個MileStone,且將build log, build完成的檔案, 和觸發這個build的相關issues關連在一起. 你可以想像, 當一個開發專案, 每天都有超過10個以上的issue, task被解決並要Build後驗證這些解決的issue, 如果能把其中一些瑣碎的事交由script來自動執行, 這樣Continuous Integration是不是更有效率一些?
附註: O. David在他的簡報並沒有提到unit test, 可能是每個專案的unit test框架不太一樣, 例如Java使用JUnit, .Net使用NUnit, Cocoa使用OCTest,所以他略過了. unit test可以在build script中設定理論上是沒問題的.
留言