Gitlab是經常使用的開源git代碼管理工具之一,隨着發展也推出了ci/cd解決方案.
顧名思義具體來講ci/cd主要完成如下兩個工做.html
gitlab ci/cd具備如下特性git
全部特性具體見:
https://about.gitlab.com/feat...docker
gitlab ci/cd是由獨立的runner程序完成,runner採用go語言編寫,所以能夠很好的進行跨平臺,一般能夠將runner部署到任何gitlab server以外的服務器,從而避免對gitlab server的影響.安全
runner項目見:
https://gitlab.com/gitlab-org...服務器
gitlab經過在項目的根目錄放置.gitlab-ci.yml文件來觸發pipline,文件書寫遵循yml語法,所以,歸納來講gitlab ci/cd只須要兩步,app
完成後,提交代碼時會自動根據gitlab-ci.yml的觸發條件進行執行相應的stage.工具
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的具體寫法,以及關鍵字含義見:
https://docs.gitlab.com/ee/ci...單元測試
關於gitlab爲何使用.gitlab-ci.yml,見:
https://about.gitlab.com/2015...測試
runner配置主要分爲三步:
總的來講,gitlab-ci基本上能夠完成完整的構建及發佈,但也會存在一些缺點:1.發佈部分,須要將程序部署到哪一個服務器固化到.gitlab-ci文件中,另外,若是runner上直接進行部署,那麼runner所在的機器則須要直接或間接的訪問全部的發佈的機器,這裏存在必定安全問題.2.程序發佈沒有審計,對於小公司來講,這問題可能不突出,可是當研發團隊擴大,以及公司業務增長以後,對於發佈過程的權限管理以及審計則顯得很重要.