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 檢查不通過