# CI/CD(持續性整合/部署) - 因為懶,所以更要CI/CD!概念講解! **Note**:如果想看到更多其他文章內容,歡迎到我的個人Blog https://kennychen-blog.herokuapp.com/ ![](https://i.imgur.com/Qma89f6.png) <center>(取至網路)</center> 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工具手把手教學!歡迎大家觀看^^