- Android APP 專案 * 1
- 自動定期查詢 SVN Server,若有更新就開始建構流程。
- 在 Jenkins Server 上安裝 Android SDK,搭配 Android 產生出來的 build.xml 建構 APK。
- 搭配 ANTS 用廠商提供的 jar 簽署 APK。
- 封存最終的 APK(只保留最新10筆),可直接從 Jenkins Server 上下載。
- ASP.Net 專案 * 1
- 手動去 SVN Server 抓 Code,開始建構流程。
- 搭配 Linux Script 針對測試環境 / 正式環境去改關鍵設定檔內容。
- 將 Project 排除掉不需要的資料夾(.git, .svn ...etc)打包成 zip 檔。
- 將 Project / zip 檔上傳至測試環境 / 正式環境。
- Java SE 專案 * 1
- 自動定期查詢 git Server,若有更新就開始建構流程。
- 在 Jenkins Server 上專裝 Java SDK,搭配 ANTS 產生 jar 檔。
- 封存最終的 jar 檔(只保留最新10筆),可直接從 Jenkins Server 上下載。
流水線的建置
基本上所有行為都還是要 Jenkins Server 要先安裝好工具,再找 Jenkins 上有無別人開發好的 Plug-in 去介接這些工具,簡化設定流程。真的都沒有才會考慮用 linux / windows command 的方式去接。比如要導入 Selenium 進行瀏覽器做自動化測試,那 CI Server 就要先安裝 Selenium 和 Firefox 等,像我目前的 CI Server 只是一台沒有 GUI Shell 的 Linux ,想要用 Selenium 就 GG 了!
方便
一鍵產出檔案,然後網頁上就可以直接下載。我就不用自己包好然後才 mail 寄給大家,之後還要考慮到其他人到底是用哪個版本的問題,直接就丟 URL 請對方下載就好!一鍵就發佈網站。明明只是改幾行,但部署到主機上有很多眉眉角角(主機位址帳號密碼,哪些檔案不能覆蓋...etc),一定要翻文件才能一步步做,現在一鍵就完成了,若發佈有問題,馬上拉上一版的 Code 一鍵 rollback。
目前這台 Jenkins Server 也只是台 VM,VM 備份出來在其他實體機器上還原就又可以 build code 了,接手的人只要會改 Code 會上版本控管就夠了,這可比寫文件來得實用多了。
陣痛期
痛的點大概就是:先搞懂什麼是 CI > 搞懂 Jenkins 怎麼使用 > 搞懂 Jenkins 可以做哪些事情 > 搞懂各種專案怎麼建置
考量到現在 IDE 太強大了,很多人(包括我)都只會利用 IDE 產出檔案。但導 Jenkins 就必須要自己跳下來弄懂 Build Code Command,流程和背後的原理,這的確是有心要精進自己軟體開發能力的人不得不去碰的,要不然就會被 IDE 綁定,明明都是 Java Web 專案卻只能用 NetBean 某一版開發?
此外,你做出來的成果是可以被重用的,因為 Jenkins 也不過就是台會做事的主機,而且提供 Web 介面,其他人只要上去按的鈕就開始跑了。這樣的改變,比你拿一個 build.xml 讓其他人去用來的讓人接受...
目前結論
如果你已經有了自己的建構流程(ANTS,Grandle,Script...etc),可以重新把這些東西整合進 Jenkins,其他人也就在不知不覺中用到這些成果。如果你連自動化建構還不了解,那還是先從寫寫 ANTS 開始。以 Java 來說,寫桌面程式就包一個 jar,寫網頁程式不就包一個 war 然後 FTP 上傳,寫 Android APP 就包一個 apk,初期沒有要導 unit test,code style 檢查這些東西,其實要弄懂的東西也就是如何擺脫 IDE 自己包檔案出來罷了,對很多以前 筆記本 + 命令列 的前輩應該都是一片蛋糕。
對於團隊來說,至少我覺得導入 CI Tool 會減少人員請假或是離職交接所帶來的衝擊。再來考慮到補上單元測試,整合測試,程式碼風格檢查這些東西,能夠大大增加專案發佈的信心和品質。
參考:CI Server 30 - Jenkins總回顧
沒有留言:
張貼留言
非常歡迎訪客留言發表感想!
但請不要暱名幹醮! XD