今天 leader 給了我一個(gè)任務(wù)，針對以下 git 分支需要走 CI 流程

master
iteration/*

簡單翻閱了 gitlab-ci 的文檔，找到了 only這個(gè)關(guān)鍵字，于是洋洋灑灑的寫出了核心配置

only:
  - master
  - /^iteration\/*$/

只見 leader 輕蔑一笑，讓我去測試一下 merge request 流程。
一種不祥的預(yù)感涌上心頭......

gitlab-ci是 git官方的持續(xù)集成工具。
什么是持續(xù)集成呢？

持續(xù)集成是一種軟件開發(fā)實(shí)踐，即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作，通常每個(gè)成員每天至少集成一次，也就意味著每天可能會(huì)發(fā)生多次集成。 每次集成都通過自動(dòng)化的構(gòu)建（包括 編譯 ，發(fā)布，自動(dòng)化測試）來驗(yàn)證，從而盡早地發(fā)現(xiàn)集成錯(cuò)誤。 ------ 百度百科

百科介紹的已經(jīng)挺全面的了，核心就在于自動(dòng)化的編譯，發(fā)布和測試。
這里舉個(gè)例子詳細(xì)解釋一下。
想象一下，我們在 feature_develop分支上完成了本次的開發(fā)，提交 merge request（mr）然后合并到 master分支上
master分支接受了我們的提交，master分支代碼發(fā)生了變化，如果我們此時(shí)需要檢查一下剛剛的修改，我們需要手動(dòng)編譯發(fā)布。而持續(xù)集成能以腳本的方式幫我們完成這一系列過程。

持續(xù)集成的過程中，我們需要檢測到某個(gè)分支的變化，或者某種行為的發(fā)生，從而觸發(fā)自動(dòng)構(gòu)建的操作（上述例子中就是master分支的修改），于是我們使用了 gitlab-ci工具，它能夠根據(jù)給定的配置檢測行為的發(fā)生（類似于前端中的事件監(jiān)聽），而具體自動(dòng)化工具的構(gòu)建過程，由于該過程會(huì)占用大量的資源，所以我們可以交給 gitlab runner來實(shí)現(xiàn)。

CI 的基本流程我們已經(jīng)知道了，我們也知道了 gitlab-ci 的具體作用是干嘛的了，我們回到 leader交給我的問題。在我們的 CI 過程中，其實(shí)除了自動(dòng)化編譯，還有個(gè)很重要的步驟，單元測試，我們的 CI會(huì)根據(jù)我們的代碼自動(dòng)去執(zhí)行其中的單元測試部分，單元測試不通過，那么此次 mr 是不會(huì)被合并到我們的 master分支上的。

我們來看核心配置部分，根據(jù) gitlab-ci 的文檔，only 關(guān)鍵字能夠指定具體的分支和部分行為，master和 iteration/* 分支我們已經(jīng)指定完成了，每當(dāng)這些分支上發(fā)生代碼變化時(shí)會(huì)自動(dòng)執(zhí)行 CI 流程，那我們漏掉了什么步驟呢？merge request 提交，在我們 mr 提交的過程中，如果我們的單元測試沒有通過，但是由于沒有觸發(fā)CI過程，master很可能會(huì)接受我們的 mr，而等到 master接受之后，再去執(zhí)行單元測試已經(jīng)沒有太大的意義了，所以，我們應(yīng)該在分支提交 mr 時(shí)就去執(zhí)行 CI 流程，從而保證，master合并的 mr 是已經(jīng)通過了單元測試的。于是，正確的核心配置應(yīng)該如下

only:
  - master
  - /^iteration\/*$/
  - merge_requests