今天 leader 給了我一個任務(wù)，針對以下 git 分支需要走 CI 流程
master
iteration/*
簡單翻閱了 gitlab-ci 的文檔鲤氢，找到了 only這個關(guān)鍵字，于是洋洋灑灑的寫出了核心配置
only:
- master
- /^iteration\/*$/
只見 leader 輕蔑一笑晌坤，讓我去測試一下 merge request 流程程奠。
一種不祥的預(yù)感涌上心頭......
gitlab-ci是 git官方的持續(xù)集成工具丈牢。
什么是持續(xù)集成呢？
持續(xù)集成是一種軟件開發(fā)實踐瞄沙，即團隊開發(fā)成員經(jīng)常集成他們的工作己沛，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成距境。 每次集成都通過自動化的構(gòu)建（包括 編譯 申尼，發(fā)布，自動化測試）來驗證垫桂，從而盡早地發(fā)現(xiàn)集成錯誤师幕。 ------ 百度百科
百科介紹的已經(jīng)挺全面的了，核心就在于自動化的編譯诬滩，發(fā)布和測試霹粥。
這里舉個例子詳細(xì)解釋一下。
想象一下疼鸟，我們在 feature_develop分支上完成了本次的開發(fā)后控，提交 merge request（mr）然后合并到 master分支上
master分支接受了我們的提交，master分支代碼發(fā)生了變化空镜，如果我們此時需要檢查一下剛剛的修改浩淘，我們需要手動編譯發(fā)布。而持續(xù)集成能以腳本的方式幫我們完成這一系列過程吴攒。
持續(xù)集成的過程中张抄，我們需要檢測到某個分支的變化，或者某種行為的發(fā)生舶斧，從而觸發(fā)自動構(gòu)建的操作（上述例子中就是master分支的修改）欣鳖，于是我們使用了 gitlab-ci工具，它能夠根據(jù)給定的配置檢測行為的發(fā)生（類似于前端中的事件監(jiān)聽）茴厉，而具體自動化工具的構(gòu)建過程泽台，由于該過程會占用大量的資源，所以我們可以交給 gitlab runner來實現(xiàn)矾缓。
CI 的基本流程我們已經(jīng)知道了怀酷，我們也知道了 gitlab-ci 的具體作用是干嘛的了，我們回到 leader交給我的問題嗜闻。在我們的 CI 過程中蜕依，其實除了自動化編譯，還有個很重要的步驟，單元測試样眠，我們的 CI會根據(jù)我們的代碼自動去執(zhí)行其中的單元測試部分友瘤，單元測試不通過，那么此次 mr 是不會被合并到我們的 master分支上的檐束。
我們來看核心配置部分辫秧，根據(jù) gitlab-ci 的文檔，only 關(guān)鍵字能夠指定具體的分支和部分行為被丧，master和 iteration/* 分支我們已經(jīng)指定完成了盟戏，每當(dāng)這些分支上發(fā)生代碼變化時會自動執(zhí)行 CI 流程，那我們漏掉了什么步驟呢甥桂？merge request 提交柿究，在我們 mr 提交的過程中，如果我們的單元測試沒有通過黄选，但是由于沒有觸發(fā)CI過程蝇摸，master很可能會接受我們的 mr，而等到 master接受之后糕簿，再去執(zhí)行單元測試已經(jīng)沒有太大的意義了探入，所以狡孔，我們應(yīng)該在分支提交 mr 時就去執(zhí)行 CI 流程懂诗，從而保證，master合并的 mr 是已經(jīng)通過了單元測試的苗膝。于是殃恒，正確的核心配置應(yīng)該如下
only:
- master
- /^iteration\/*$/
- merge_requests
