CI/CD (持續性整合 / 部署) - 因為懶，所以更要 CI/CD！概念講解！

CI/CD (Continuous Integration/Continuous Deployment 或是 Continuous Delivery) 這個概念近年來在業界也是越來越火紅，一部分也是因為敏捷式開發的風潮帶動 CI/CD，其實講白了就是為了兩個字：方便，CI/CD 就是減輕人工的負擔，使得一切都能自動化實現。實現甚麼事情呢？我們來一個一個來看名詞解釋：

CI (Continuous Integration) 持續整合

build 程式建置 (編譯)

當一個團隊共通開發一個專案的時候，一定都會使用版本控制，當每次 commit&push，需要保證 push 上去後的程式碼不會導致整個專案無法編譯成功，例如有可能環境變數、版本套件的原因導致這些問題。但是這些苦功如果都要我們工程式每次 push 上新的版本都要親自手動編譯實在也太麻煩了，因此就需要自動化的流程幫我們自動編譯好，看新 push 上去的程式碼有沒有出現錯誤。

unit test 單元測試

前面當自動化的流程幫我們編譯好程式後，下一步就是要就是進行單元測試，看專案內的預先寫好的單元測試是否都有通過，如此一來才能保證新 push 上去的程式碼，不僅可以被成功建置也保證專案的功能沒有出現漏洞。當然，這也是要單元測試寫得好才行 XD 不過單元測試這東西嘛，確實如果要寫的細是會佔據工程師許多時間的，個人認為寫單元測試也是一種很大的學問的。

因此，可以知道在 CI 這個階段，不僅可以減輕團隊的 loading，工程師只需要寫好程式並且 push 上去即可，由 CI 的自動化程式幫團隊做檢查，只要發現錯誤，就能快速根據錯誤進行修改。通常一個團隊都會定好整個 CI 的測試流程，按照這個流程產生一定品質的專案。

CD (Continuous Deployment) 持續部署

部署服務

其實就是前面 CI 的自動化流程做完後，那麼接下來就是部署專案！因此 CD 其實就是透過自動化流程的方式將程式自動更新到伺服器上並使得整個專案服務可以運作，此外更好的設計就是會一併啟動監控程式，去監控服務是否有異常現象，並主動通知開發人員。

以例子來說就是假設我現在有一台虛擬機當作伺服器，我想要在裡面架設網站，所以 push 程式碼，CI 幫我檢查程式是否可以編譯成功，單元測試是否都通過，當 CI 部分都通過後，接著執行 CD 的部分，幫我把程式碼丟到伺服器上，並且架設好 web server，幫我開好對外服務等等。

所以好處就出現了，工程師的我們只需要負責寫程式，自動化檢查及部署就丟給 CI/CD 去執行吧！

常見的 CI/CD 工具

現在市面上有很多 CI/CD 工具，所以其實不需要自己寫，但唯一需要寫得通常就是 CI/CD 工具的設定檔，因為通常都會讓我們能夠自定義 CI/CD 的流程，以符合每個團隊想要流程，所以唯一要學的就是該 CI/CD 工具的運作方式及設定檔如何撰寫。同時選擇的 CI/CD 工具最好是能夠結合 Docker、各大雲端平台，這會讓我們在 CD 這方面的流程能夠更加便利。

以下列出我常看到的 CI/CD 工具：

• GitLab

  GitLab 是業界常用的程式碼儲存庫的地方，同時自己本身也推出 CI/CD 服務，因此結合性沒話說，也很方便。

• GitHub

  GitHub 在近幾年推出 CI/CD 服務，但聽說還不是很穩定。

• Jenkins

  老牌的 CI/CD 服務，缺點就在於設定檔很難撰寫，學習成本高。

• Drone

  也是近年來新出的，是一套以 Golang 開發的工具，建置速度快又便利，學習成本低 + 容易維護，新手好上手，最重要的一點它是以 Docker 為 Base 的，所有流程都是在 Docker 內完成，所以非常適合在 Kubernetes 平台啟動容器，當然缺點就是套件不多，有客製化的需求需要自行撰寫。

• Travis CI

  專門支持 GitHub 平台，所以很適合放在 GitHub 平台上的開源專案，但也是缺點，不支持其它程式庫儲存庫的平台，相對來說在業界就會用的比較少，因為 GitHub 的免費版限制很多，通常也不會以 GitHub 做為團隊的程式庫儲存庫的平台，都會跳到 GitLab 平台 XD 不過對於個人使用還是不錯的。

總結

個人覺得除了 GitHub 的還不太成熟，其它都很值得學的，畢竟在業界或是個人使用都會滿大機會碰到。因此之後會努力一一帶來各大 CI/CD 工具手把手教學！歡迎大家觀看 ^^