Jenkins 兩個月心得

寫一下這一兩個月使用 Jenkins Server 的心得，我目前使用的狀況如下：

• 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總回顧

Jenkins 初用心得

這本來算是我在前公司要弄的項目，種種原因下搞到最近我才敢講我有玩過一輪。實務部分，大概從 jenkins 建立到整合 git / svn ，成功 build 完一個 jar / android apk。理論的部分則是翻完了下面這本名字落落長的書（有機會在寫心得）。

本文記錄一下，我在 jenkins 建構完這兩個專案的想法。


Continuous Delivery中文版：利用自動化的建置、測試與部署完美創造出可信賴的軟體發佈

如果你是主管，我建議要強迫導入。

原因很簡單，下面人放假了或是人跑了，只要其他人有能力拉 code 下來修改重新 commit 回 Version Control Server，jenkins 就能直接從 Version Control Server 拉下來建立要部署的檔案。

寫的很夢幻，前面該做的苦工還是要做，比如怎麼在 linux 上包出 apk（所有 IDE 幫你做的事情你都要自己搞一次）...

如果你已經懂 ant / maven / gradle，可以看情況。

會這樣說是因為，如果專案只有你在寫，也沒 Q 要測你的東西，那我覺得只要 unit test / 整合測試在開發環境做好一套即可，多在 jenkins 搞一套，除非你時間多想多學習，要不之後對專案幫助不大。

如果別人有要測你的東西，導入 jenkins 讓大家都是在同一個地方抓檔案，不會有搞不清楚再測哪一版的狀況（我是測你昨天下午五點半給我的那一版 --> 有沒有很熟悉的感覺）。
如果有人跟你一起開發，加上單元測試，每次整合完就能知道初步結果，你的主管也能在 jenkins 上看到專案最近幾次的整合結果，大家對於整合完的結果也會有更多信心，而不是憑感覺發佈。

接下來的工作

目前已經是來當作發佈檔案（war / jar / apk）的網站使用，接下來會加入單元測試來加強整合後的驗證工作，後續會試看看整合 asp.net 和自動發佈的功能，有機會的話會寫第二篇。