GitLab-CI持續集成實踐

GitLab-CI持續集成介紹

持續集成是一種軟件開發實踐，即團隊開發成員常常集成它們的工做，經過每一個成員天天至少集成一次，也就意味着天天可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘早地發現集成錯誤。gitlab通常用Gitlab-CI，而github通常用jenkins，主要功能是在你提交或merge代碼到倉庫後，自動執行一些你定義好的命令， 好比安裝依賴、單元測試、pep8檢查、甚至還能夠自動部署到生成環境。前段時間本身給當前作的項目加上了gitlab-ci,實現的主要功能是提交代碼後自動檢測安裝依賴有沒有問題，單元測試能不能經過， pep 8 規範檢查是否合格，有一項不合格就會在提交的分支或merge後面有個顯目的紅叉， 全經過的話則是一個賞心悅目的綠色對勾。

GitLab簡單原理圖

安裝和配置Runner

首先， gitlab ci 須要單獨部署在一臺服務器上來運行， 對應的程序是GitLab Runner,
在ubuntu和centos上安裝都是先根據一個shell腳本安裝各類依賴， 而後再執行安裝程序。

# For Debian/Ubuntu    
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash    
$ sudo apt-get install gitlab-ci-multi-runner    
# For CentOS    
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash    
$ sudo yum install gitlab-ci-multi-runner

爲了可以讓GitLab Runner 可以鏈接到咱們的項目上須要註冊操做：
sudo gitlab-runner register
而後根據提示輸入配置信息（這些信息能夠在項目的gitlab網站的CI/CD 配置裏找到， 須要master權限）

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )    
https://gitlab.com  //項目gitlab的根域名， 通常公司都會部署本身內部使用的gitlab    

Please enter the gitlab-ci token for this runner    
xxx   // gitlab token, 每一個項目都不同    

Please enter the gitlab-ci description for this runner    
[hostame] my-runner  // 項目描述， 起個名稱    

Please enter the gitlab-ci tags for this runner (comma separated):    
my-tag,another-tag   // 給該 Runner 指派 tags, 稍後也能夠在 GitLab's UI 修改, 這裏也能夠直接回車， 使用默認值    

Whether to run untagged jobs [true/false]:    
[false]: true   // 選擇 Runner 是否接收未指定 tags 的任務（默認值：false）， 稍後能夠在 GitLab's UI 修改    

Whether to lock Runner to current project [true/false]:    
[true]: false // 該runner是否只能運行當前指定項目（根據token來判斷的），默認值：true：    

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:    
shell  // 選擇runner的類型， 這裏用shell就好

配置完成， sudo gitlab-runner list 能夠查看當前runner的狀態。

pipeline 配置

GitLab Runner 啓動成功後接下來就是在你的項目裏配置gitlab ci要幹哪些事情了， 在項目的根目錄新建一個.gitlab-ci.yml 文件，在裏邊配置代碼commit後gitlab ci要乾的事情。一個簡單的示例以下：

# 定義 stages    
stages:    
  - build    
  - test    
# 定義 job    
job1:    
  stage: test    
  script:    
    - echo "I am job1"    
    - echo "I am in test stage"    
# 定義 job    
job2:    
  stage: build    
  script:    
    - echo "I am job2"    
    - echo "I am in build stage"

執行順序以下：

1. stages裏的stage按順序執行， 若是有一個stage執行失敗， 結束， 再也不往下執行。
2. 執行每一個stage時，stage裏的job並行執行， 全部job都執行成功該stage纔算成功， 有一個失敗的話該stage執行失敗， 結束。

此外，還有連個很是有用的選項——before_script 和 after_script, 分別對應着每一個job執行先後要運行的額外代碼。
更多的配置選項能夠看gitlab ci的官方文檔

pep 8

當多人蔘與一個項目時， 統一代碼規範就很重要。 python通常用的是pep 8， 用flake 8 能夠很方便作到。

1. 安裝

   pip install flake8 pep8-naming

2. 在項目根目錄下新建一個.flake8配置文件
3. 配置文件內容大概以下（不要出現中文， 後面的註釋是爲了便於讀者理解額外添加的）：

[flake8]    
ignore = W292 W391 E126 W291 N805  // 忽略的格式類型    
exclude =  // 忽略的文件、文件夾    
    *migrations*,    
    # python related    
    *.pyc,    
    .git,    
    __pycache__,    
    *.conf,    
    *.md,    
    config*    
    *settings*    
    manage.py    
    gold/vulpo/*    


max-line-length=125  // 單行最大字數    
max-complexity=16  // 複雜度上限    
format=pylint      
show_source = True    
statistics = True    
count = True

固然， 記得在.gitlab-ci.yml 中添加一個執行pep 8 檢查的job：

pep8_test:    
    stage: pep8    
    script:    
        - flake8 gold    
#    allow_failure: true   // 有追求的程序員固然不會容許pep 8 檢查不經過