Gitlab是經常使用的開源git代碼管理工具之一,隨着發展也推出了ci/cd解決方案. 顧名思義具體來講ci/cd主要完成如下兩個工做.html
ci(持續構建)
代碼提交後觸發自動化的單元測試,代碼預編譯,構建鏡像,上傳鏡像等.git
cd(持續發佈)
持續發佈則指將構建好的程序發佈到各類環境,如預發佈環境,正式環境.docker
gitlab ci/cd具備如下特性安全
全部特性具體見: 連接bash
gitlab ci/cd是由獨立的runner程序完成,runner採用go語言編寫,所以能夠很好的進行跨平臺,一般能夠將runner部署到任何gitlab server以外的服務器,從而避免對gitlab server的影響.服務器
runner項目見:連接app
gitlab經過在項目的根目錄放置.gitlab-ci.yml文件來觸發pipline,文件書寫遵循yml語法,所以,歸納來講gitlab ci/cd只須要兩步,工具
stages:
- test
- build
- deploy
test:
stage: test
script: echo "Running tests"
only:
- tags
build:
stage: build
script: echo "Building the app"
only:
- tags
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
only:
- tags
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
environment:
name: production
url: https://example.com
when: manual
only:
- tags
複製代碼
如上,是一個具備ci/cd功能的.gitlab-ci.yml文件的寫法,gitlab
.gitlab-ci.yml的具體寫法,以及關鍵字含義見: 連接單元測試
關於gitlab爲何使用.gitlab-ci.yml,見: 連接
runner配置主要分爲三步:
總的來講,gitlab-ci基本上能夠完成完整的構建及發佈,但也會存在一些缺點: 1.發佈部分,須要將程序部署到哪一個服務器固化到.gitlab-ci文件中,另外,若是runner上直接進行部署,那麼runner所在的機器則須要直接或間接的訪問全部的發佈的機器,這裏存在必定安全問題. 2.程序發佈沒有審計,對於小公司來講,這問題可能不突出,可是當研發團隊擴大,以及公司業務增長以後,對於發佈過程的權限管理以及審計則顯得很重要.