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 和自動發佈的功能,有機會的話會寫第二篇。

4 則留言:

  1. 屌...這麼快就摸完一次
    除了節省人力以外,另外的好處就是建立一個大家都能follow的development process , 如你所說, 這樣的產出大家是會有信心的, 也是其中價值所在

    回覆刪除
  2. Commit前,要先測過,不要直接放給自動化測試,會比較順。 😣

    回覆刪除
  3. 開發者在 local 端要自己先 run 過自動化測試
    master 原則上理想上要是能 build 過能通過測試的版本

    回覆刪除

非常歡迎訪客留言發表感想!
但請不要暱名幹醮! XD