Gitlab的CI/CD介紹
簡介
背景
目前市面上常用的自動化部署的工具比較常見的是Jenkins，但是使用過程中，總會遇到各種奇奇怪怪的錯誤，很難定位問題所在；今天我要介紹的gitlab中的CI/CD功能，個人覺得部署起來更加簡單，有效，易排查，可視化界面也更加整潔～
後面將通過以下幾篇文章，學習和介紹Gitlab中CI/CD的整體流程
- Gitlab的CI/CD學習(一) —— 簡介
- Gitlab的CI/CD學習(二) —— .gitlab-ci.yml文件
- Gitlab的CI/CD學習(三) —— gitlab-runner
基本概念
CI 持續集成（Continuous Integration）
現代應用開發的目標是讓多位開發人員同時處理同一應用的不同功能。但是，如果企業安排在一天內將所有分支源代碼合併在一起（稱爲“合併日”），最終可能造成工作繁瑣、耗時，而且需要手動完成。這是因爲當一位獨立工作的開發人員對應用進行更改時，有可能會與其他開發人員同時進行的更改發生衝突。如果每個開發人員都自定義自己的本地集成開發環境（IDE），而不是讓團隊就一個基於雲的 IDE 達成一致，那麼就會讓問題更加雪上加霜。
持續集成（CI）可以幫助開發人員更加頻繁地（有時甚至每天）將代碼更改合併到共享分支或“主幹”中。一旦開發人員對應用所做的更改被合併，系統就會通過自動構建應用並運行不同級別的自動化測試（通常是單元測試和集成測試）來驗證這些更改，確保這些更改沒有對應用造成破壞。這意味着測試內容涵蓋了從類和函數到構成整個應用的不同模塊。如果自動化測試發現新代碼和現有代碼之間存在衝突，CI 可以更加輕鬆地快速修復這些錯誤。
CD 持續交付（Continuous Delivery
完成 CI 中構建及單元測試和集成測試的自動化流程後，持續交付可自動將已驗證的代碼發佈到存儲庫。爲了實現高效的持續交付流程，務必要確保 CI 已內置於開發管道。持續交付的目標是擁有一個可隨時部署到生產環境的代碼庫。
在持續交付中，每個階段（從代碼更改的合併，到生產就緒型構建版本的交付）都涉及測試自動化和代碼發佈自動化。在流程結束時，運維團隊可以快速、輕鬆地將應用部署到生產環境中。
CD 持續部署（Continuous Deployment）
對於一個成熟的 CI/CD 管道來說，最後的階段是持續部署。作爲持續交付——自動將生產就緒型構建版本發佈到代碼存儲庫——的延伸，持續部署可以自動將應用發佈到生產環境。由於在生產之前的管道階段沒有手動門控，因此持續部署在很大程度上都得依賴精心設計的測試自動化。
實際上，持續部署意味着開發人員對應用的更改在編寫後的幾分鐘內就能生效（假設它通過了自動化測試）。這更加便於持續接收和整合用戶反饋。總而言之，所有這些 CI/CD 的關聯步驟都有助於降低應用的部署風險，因此更便於以小件的方式（而非一次性）發佈對應用的更改。不過，由於還需要編寫自動化測試以適應 CI/CD 管道中的各種測試和發佈階段，因此前期投資還是會很大。
流程
.gitlab-ci.yml
爲上述CI集成的核心體現，用於表達每一次代碼提交後的處理步驟、和執行任務
gitlab-runner
爲服務器中的監聽者和執行者；可通過監聽的形式，在通過url和token綁定對應倉庫後，代碼提交後，runner負責拉取代碼並根據.gitlab-ci.yml配置文件配置的步驟和任務持續執行、部署。
原理
在gitlab項目根目錄中上傳好 .gitlab-ci.yml 文件,服務器註冊的gitlab-runner用於監聽gitlab項目修改並在服務器中執行對應命令或腳本。固要求就是服務器能夠正常訪問到gitlab倉庫即可。