最近我們團(tuán)隊(duì)準(zhǔn)備用gitlab的cicd功能提升工作效率，這里做一些記錄。

一、CI/CD 介紹

「持續(xù)集成（Continuous Integration）」、「持續(xù)交付（Continuous Delivery）」和「持續(xù)部署（Continuous Deployment）」三個(gè)概念的認(rèn)識(shí)

持續(xù)集成

持續(xù)集成指的是頻繁地將代碼集成到主干，強(qiáng)調(diào)開發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建、（單元）測(cè)試。根據(jù)測(cè)試結(jié)果，我們可以確定新代碼和原有代碼能否正確地集成在一起。持續(xù)集成的目的，就是讓產(chǎn)品可以快速迭代，同時(shí)還能保持高質(zhì)量。它的核心措施是，代碼集成到主干之前，必須通過自動(dòng)化測(cè)試。只要有一個(gè)測(cè)試用例失敗，就不能集成。

持續(xù)交付

持續(xù)交付指的是，頻繁地將軟件的新版本，交付給質(zhì)量團(tuán)隊(duì)或者用戶，以供評(píng)審。如果評(píng)審?fù)ㄟ^，代碼就進(jìn)入生產(chǎn)階段。持續(xù)交付可以看作持續(xù)集成的下一步。它強(qiáng)調(diào)的是，不管怎么更新，軟件是隨時(shí)隨地可以交付的。

持續(xù)部署

持續(xù)部署是持續(xù)交付的下一步，指的是代碼通過評(píng)審以后，自動(dòng)部署到生產(chǎn)環(huán)境。持續(xù)部署的目標(biāo)是，代碼在任何時(shí)刻都是可部署的，可以進(jìn)入生產(chǎn)階段。

持續(xù)交付和持續(xù)部署的區(qū)別

說白了，持續(xù)交付就是自動(dòng)地從倉庫將最新的程序部署到測(cè)試環(huán)境里，持續(xù)部署就是自動(dòng)地將穩(wěn)定版本部署到生產(chǎn)環(huán)境里；

持續(xù)部署和持續(xù)交付區(qū)別圖

CI/CD流程

一般每個(gè)團(tuán)隊(duì)不一樣，這里提供一種思路：

ci/cd流.png

1. 提交
2. 測(cè)試（第一輪）
   • 單元測(cè)試：針對(duì)方法或模塊的測(cè)試（至少）
   • 集成測(cè)試：針對(duì)整體產(chǎn)品的某個(gè)功能的測(cè)試，又稱功能測(cè)試
   • 端對(duì)端測(cè)試：從用戶界面直達(dá)數(shù)據(jù)庫的全鏈路測(cè)試
3. 構(gòu)建
   通過測(cè)試后，代碼合并到主干，可以進(jìn)行構(gòu)建，所謂構(gòu)建，指的是將源碼轉(zhuǎn)換為可以運(yùn)行的實(shí)際代碼，比如安裝依賴，配置各種資源等等。
4. 測(cè)試（第二輪）
   全面測(cè)試，自動(dòng)化為主，少數(shù)無法自動(dòng)化的測(cè)試用例，就要人工跑。
   新版本的每一個(gè)更新點(diǎn)都必須測(cè)試到。
5. 部署
6. 回滾

常見CI/CD工具

• jenkins
  免費(fèi) + 插件，Jenkins閃耀的地方是其豐富的插件生態(tài)系統(tǒng)。它提供了超過1000個(gè)插件的擴(kuò)展版本，可以集成幾乎所有市場(chǎng)上可用的工具和服務(wù)。作為一個(gè)開源工具，您還可以選擇自定義適合本土解決方案。
• Bamboo
  Bamboo 是Atlassian產(chǎn)品套件的一部分，與其他工具類似，它提供構(gòu)建，測(cè)試和部署代碼并支持多種語言。它與其他與CI循環(huán)相關(guān)的Atlassian產(chǎn)品（如JIRA和Bitbucket）有很強(qiáng)的集成。
• Circle CI, Travis CI, TeamCity, CodeShip等等
• gitlab CI/CD

二、gitlab CI/CD

Gitlab持續(xù)集成是Gitlab提供的一整套持續(xù)集成、持續(xù)交付解決方案。

配置步驟

使用gitlab持續(xù)集成需要兩步（不分先后）：

1. 在repository項(xiàng)目根目錄創(chuàng)建.gitlab-ci.yml文件
   這個(gè)文件是你定義ci任務(wù)的地方，每一次push代碼到repository，gitlab都會(huì)掃描這個(gè)文件，按照上面的配置執(zhí)行相應(yīng)的任務(wù)。
   詳見.gitlab-ci.yml配置
2. 安裝并配置gitlab runner
   gitlab runner是運(yùn)行ci任務(wù)的角色，可以是一個(gè)虛擬機(jī)，一個(gè)物理機(jī)，或者一個(gè)docker容器，甚至容器集群，它和gitlab通過api進(jìn)行通信，所以唯一要求是runner到gitlab是網(wǎng)絡(luò)通的。
   在gitlab上可以在settings中進(jìn)行配置，可以看到有一些shared runner，但肯定不是我們需要的，我們要自己定制。
   以在docker上安裝為例，安裝配置步驟如下：

sudo docker pull gitlab/gitlab-runner:latest

sudo docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest
  
sudo docker exec -it gitlab-runner gitlab-ci-multi-runner register  
#提示注冊(cè)信息，這里最好不采用這種交互式的，因?yàn)橛幸恍┓潜匾呐渲眠@里不會(huì)出現(xiàn)
# 配置關(guān)聯(lián)gitlab-ci url，在項(xiàng)目settings>CI/CD>runners可以找到
Please enter the gitlab-ci coordinator URL:
# 配置token，在項(xiàng)目settings>CI/CD>runners可以找到
Please enter the gitlab-ci token for this runner:
# runner描述，隨便輸
Please enter the gitlab-ci description for this runner:
# runner的tags，這個(gè)很有用，通過tag和jobs關(guān)聯(lián)
Please enter the gitlab-ci tags for this runner (comma separated):

Whether to run untagged builds [true/false]:
# true
Please enter the executor: docker, parallels, shell, kubernetes, docker-ssh, ssh, virtualbox, docker+machine, docker-ssh+machine:
# docker
Please enter the default Docker image (e.g. ruby:2.1):
# maven:3.7.9-jdk-8

coordinator URL和token位置如下：

gitlab ci 項(xiàng)目的url和token

gitlab ci工作原理

從前文中我們已經(jīng)知道，有幾個(gè)角色：

• gitlab
• runner
• executor
  gitlab觸發(fā)條件后，會(huì)通知給對(duì)應(yīng)的runner，runner并不是命令執(zhí)行者，而是類似一個(gè)調(diào)度器或者說中介，真正干活的是executor，我們完全可以構(gòu)建自己的executor來滿足我們的CI需求。比如通過docker自定義容器實(shí)現(xiàn)（docker是個(gè)好東西）。

三、我們的CI/CD方案（擬）

因?yàn)槲覀儺a(chǎn)品上線是在公司有嚴(yán)格控制的，所以CD中最后一步“部署上線”肯定是滿足不了的，策略就是從提交代碼開始，到測(cè)試環(huán)境的部署測(cè)試。結(jié)合實(shí)際項(xiàng)目情況，方案圖例如下：

方案圖.png

首先只有mr動(dòng)作觸發(fā)我們的pipeline，進(jìn)行單測(cè)，單測(cè)通過后部署到測(cè)試環(huán)境中，然后跑自動(dòng)化測(cè)試，都通過后，由代碼reveiwer惹怒元不能自動(dòng)化的新功能新需求，通過后補(bǔ)充手動(dòng)測(cè)試，QA確認(rèn)通過后整個(gè)流結(jié)束，

gitlab ci可以和jenkins進(jìn)行集成，這個(gè)后面再討論。