GitLab持續集成在商用項目中的應用實踐

兩年前在開始一個新的商業項目時我花了兩個星期時間在項目開發流程中應用上了持續集成，隨後一年又隨着項目的發展和商用化作了不少改進。因此掌握了GitLab 持續集成這套方案在商業軟件中完整的落地實踐經驗。文章最先發布在其餘平臺，當時引發了很多關注，內容雖然是對一個PHP項目持續集成的設置，可是整個持續集成是徹底容器化的，這套方法論能夠很方便的應用於任何編程語言的項目。

關注文章下方公衆號，關鍵字回覆CI能夠獲取完整的持續集成方案的編排文件和容器的Dockerfile 源碼。

GitLab CI/CD

Gitlab持續集成是Gitlab提供的一整套持續集成、持續交付解決方案。Gitlab自9.0版本開始增長了CI和CD功能，因此若是你的公司裏的Gitlab上在Settings裏找不到關於CI/CD的配置項那麼大家確實該對公司的GitLab進行升級了。

咱們公司以前項目部署一直在用一個叫瓦力的工具，雖然也能實現交付項目的功能可是也有很多弊端，好比：

1. 前置任務和後置任務功能不夠強大，須要專門寫shell腳原本完成複雜的任務。
2. build環境永遠是一套，公司裏有的php項目用的版本有5.六、7.0、7.1 ，java項目依賴的jdk版本不一樣，這些版本都會相互排斥，一旦一個版本的項目構建成功後一定會影響其餘版本的項目。
3. 構建過程和構建結果不夠可視化。

後來公司有的項目陸陸續續開始使用GitLab CI，由於當時對這套解決方案研究不深不知道該如何在CI上進行代碼回滾，如何管控生產環境的部署上線（好比只有權限高的人才能部署測試環境、構建完成後想手動部署生產環境而不是push後自動部署）因此只用來作構建和部署測試環境的代碼。與此同時執行CI Jobs的機器仍然是一臺物理機，上面須要全局安裝了這些構建工具來完成項目構建工做，這仍然會遇到上面第二點項目代碼版本依賴的衝突。

因爲我本身如今在公司一個重點項目裏作架構師，在項目開始之初就有打算將持續集成和持續交付這裏好好梳理一下，解決上面這些比較突出的問題。最近因爲這些問題爆發的愈來愈嚴重以爲有義務拿出一套比較好的解決方案來解決這些問題因此一直在研究解決這些問題的方案。

隨着對Gitlab CI 這套方案理解的加深慢慢制定了以下的策略：

1. 使用Docker來做爲git runner 的executor（執行器），這樣在每一個Job完成後都會清理build環境。
2. 應用不一樣的docker鏡像來解決構建代碼版本依賴的問題（php7的項目用php7的鏡像起的容器來執行構建工做，5.6的就用php5.6 鏡像起的容器去執行構建工做）
3. 控制Git工做流，針對不一樣功能的代碼分支分別寫CI Job去執行構建、測試和部署的工做。而且master只接受合併請求不容許任何人push， 這樣就可以控制發佈正式環境的時間點了，並且部署操做除了push自動觸發外也能夠配置成在GitLab項目頁面裏手動點擊按鈕來部署。

我基本上是將CI分紅build , test, deploy三個階段，build裏主要就是完成項目代碼依賴包的安裝（composer 和 npm install 之類的工做， 咱們先後端是兩個項目，前端項目事先須要針對不一樣環境配置不一樣的打包命令）。

build:
  stage: build
  image: kevinyan001/git-runner:php7.1-node10
  script:
    - /usr/local/bin/composer install
  only:
    - develop
    - uat
  tags:
    - your-runner-tag

test階段會去執行項目中編寫的測試用例:

test-dev:
  stage: test
  image: kevinyan001/git-runner:php7.1-node10
  script:
    - php artisan migrate --force
    - ./vendor/bin/phpunit
  only:
    - develop
  tags:
    - your-runner-tag

deploy階段完成項目最後的部署和一些服務器reload操做最終將項目交付上線。

deploy-testing:
  stage: deploy
  script:
    - rsync -az --delete --exclude=.git --exclude=.gitignore --exclude=.gitlab-ci.yml ./ $SERVER_TOKEN_TEST:$WEB_ROOT_TEST
    - ssh $SERVER_TOKEN_TEST -t "chown -R www:www ${WEB_ROOT_TEST}"
  environment:
    name: test
    url: http://test.example.com
  only:
    - develop
  tags:
    - your-runner-tag

說明：

• 任務中的$SERVER_TOKEN_TEST這些是提早在GitLab項目的Settings --> CI/CD Pilelines裏定義的變量，執行任務時容器會在BASH SHELL中讀入這些預先定義的變量。
• $SERVER_TOKEN_TEST裏設置的內容是user@server_ip, ${WEB_ROOT_TEST}裏設置的是項目在服務端的路徑。
• 我在容器的鏡像裏安裝了ansible, 發佈正式環境時使用ansible將項目部署到正式環境對應的多個主機上。

git runner會在每一個Job的開始階段經過鏡像kevinyan001/git-runner:php7.1-node10 跑一個容器，在容器中執行這些操做，等Job執行完後容器會被中止並清理掉，這就須要咱們在每次容器起來的時候在容器裏執行一些預備工做，好比與目標服務器創建信任關係這些基礎的工做，我是經過將SSH PRIVATE KEY注入到容器中，目標服務器事先放上對應的公鑰來創建容器與目標主機的信任關係的：

before_script:
  - mkdir -p ~/.ssh
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r'  > /root/.ssh/id_rsa
  - chmod -R 600 ~/.ssh
  - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
  - chmod 644 ~/.ssh/known_hosts
  - mkdir -p /etc/ansible
  - echo 'xx.xx.xxx.xxx db_master' >> /etc/hosts #make container can connect to mysql server
  - echo 'xx.xx.xxx.xxx db_slave' >> /etc/hosts

具體能夠參考gitlab ci關於這一塊的說明文檔：https://docs.gitlab.com/ee/ci...

因爲GitLab CI的功能很是多，可配置像也不少因此具體某個配置的做用我就不細說了，貼幾個我認爲比較有用的說明文檔出來節省你們的搜索時間。
https://docs.gitlab.com/runne...
https://docs.gitlab.com/ee/ci/
https://docs.gitlab.com/ee/ci...
https://docs.gitlab.com/ee/ci...
https://docs.gitlab.com/ee/ci...

kevinyan001/git-runner:php7.1-node10是我作的一個專門用來跑CI任務的容器的鏡像，已經上傳到了 Docker 官方的鏡像源中能夠直接使用。你能夠針對你的需求製做其餘的鏡像。關注下面公衆號回覆CI能夠得到源版的Dockerfile。

Conclusion

GitLab CI/CD提供了一套通用的解決方案讓你從最初的Coding開始到最後代碼交付上線都能在它提供的工具集合中輕鬆完成，經過Git Runner的Executor執行不一樣階段定製的任務進行代碼build、集成測試、和部署上線。除此以外還能夠幫咱們完成API文檔生成、代碼檢查、Wiki文檔構建等工做，只要在Linux Bash Shell中能實現的任務它都能幫你實現。它支持用不少不一樣類型的Executor來執行CI Jobs，其中我最推薦使用的類型是Docker Executor，這樣咱們的build環境就不依賴於Git Runner宿主機上的環境，從而可以應用不一樣容器完成各類不一樣項目的構建工做。