本文記錄一下,我在 jenkins 建構完這兩個專案的想法。
Continuous Delivery中文版:利用自動化的建置、測試與部署完美創造出可信賴的軟體發佈
如果你是主管,我建議要強迫導入。
原因很簡單,下面人放假了或是人跑了,只要其他人有能力拉 code 下來修改重新 commit 回 Version Control Server,jenkins 就能直接從 Version Control Server 拉下來建立要部署的檔案。寫的很夢幻,前面該做的苦工還是要做,比如怎麼在 linux 上包出 apk(所有 IDE 幫你做的事情你都要自己搞一次)...
如果你已經懂 ant / maven / gradle,可以看情況。
會這樣說是因為,如果專案只有你在寫,也沒 Q 要測你的東西,那我覺得只要 unit test / 整合測試在開發環境做好一套即可,多在 jenkins 搞一套,除非你時間多想多學習,要不之後對專案幫助不大。如果別人有要測你的東西,導入 jenkins 讓大家都是在同一個地方抓檔案,不會有搞不清楚再測哪一版的狀況(我是測你昨天下午五點半給我的那一版 --> 有沒有很熟悉的感覺)。
如果有人跟你一起開發,加上單元測試,每次整合完就能知道初步結果,你的主管也能在 jenkins 上看到專案最近幾次的整合結果,大家對於整合完的結果也會有更多信心,而不是憑感覺發佈。
屌...這麼快就摸完一次
回覆刪除除了節省人力以外,另外的好處就是建立一個大家都能follow的development process , 如你所說, 這樣的產出大家是會有信心的, 也是其中價值所在
原來有留言
回覆刪除我漏看了
Commit前,要先測過,不要直接放給自動化測試,會比較順。 😣
回覆刪除開發者在 local 端要自己先 run 過自動化測試
回覆刪除master 原則上理想上要是能 build 過能通過測試的版本