上一篇提到主幹開發裡其中一個要點是每天最少合併一次branch到trunk，這能確保我們的source code時常保持著最新的功能。這時候就需要build automation工具了。其實把這些軟體歸類到build automation對他們有點不公平，因為他們現在已經包含許多更多的功能了。

比較常見的軟體有：
Jenkins
GitLab CI
Spinnakar
TeamCity
Azure DevOps
BitBucket

到現在最常見的還是jenkins，不過我接觸到的公司越來越多開始使用GitLab或Azure DevOps等。

這篇用GitHub和Jenkins為例。如果想用GitLab的話，去年Cheng Wei的DevOps組冠軍文章，和艦長一起 30 天玩轉 GitLab 系列是一個非常好的資源。

我們想達到的功能是在每一次commit的時候，build automation會自動組建軟體，測試功能，然後存到一個可以被release automation接收的位置。這可以是個shared drive，不過比較好的選擇是放到artifact repository裡（下一篇會詳細探討artifact repository)。

GitHub和Jenkins的連結是運用webhook。我們需要在GitHub裡設定webhook，

然後在Jenkins pipeline裡要設定這個pipeline關聯的GitHub repository網址。

連結設定好了後，下一步就是定義build pipeline裡的步驟。下圖可見我們的pipeline裡有四個步驟，從GitHub裡checkout原始碼，組建軟體，測試功能，把測試完的軟體放到shared drive裡，然後啟動release automation process(deploy)。

這一個Jenkins project的pipeline定義儲存在一個jenkinsfile裡，和source code放在一起。這能讓開發者自己定義pipeline裡的步驟。

這幾個步驟裡重要的有兩點：

1. Commit message裡應該要包含user story number，這樣所有的測試結果能夠update到agile planning軟體裡。
2. Jenkins到release automation軟體的連結中應包含build number。這兩個號碼會成為這一版軟體的“身分證號碼”，能讓我們追蹤從build到release的所有動向。

下一篇我們來看一下Artifact repository的功能和我們為什麼需要使用artifact repository。

< 上一篇 Day09 - Source code branching
> 下一篇 Day11 - Continuous Integration - Artifact repository