關於CI/CD的兩三事

CI/CD，全名叫做Continuous Integration / Continuous Delivery，中文名叫持續集成與持續交付，從2014年開始，得以有幸接觸了從零開始的CI/CD的搭建以及流程梳理，也有在一個已經既有的開發體系中，如何去逐步導入CI/CD的相關經驗，透過這篇文章分享一下自己多年以來對於CI/CD的經驗與心路歷程。

關於持續集成與持續交付

在目前軟體業界普遍以敏捷開發作為精神，必須透過連續的小型的開發循環(Sprint)來迭代我們的產品以及驗證需求，以這樣為前提之下，我們必須不斷地從需求、研發、測試、交付，中多個階段不斷地循環迭代。所以我們為了上述的概念，我們必須有了持續集成與持續交付。

持續集成與持續交付，對於我個人的理解來說有以下來幾個重點。

• 讓開發團隊可以在一個不斷提升開發品質的體系當中。
• 從**需求、研發、測試、交付**四個階段中能夠有一套完整且嚴格的體系及框架。
• 自動化節省時間 - 讓開發團隊從一些瑣事的泥沼中解放出來。
• 減少風險 - 因為有了上述幾點，所以可以有效提升軟體品質，而不會因為迭代過快造成軟體工程的不穩定。

CI/CD 的建立與導入

在過去的經驗當中，要在一個團隊一次導入這個概念其實是相對困難的，不管是重頭開始，或者是在一半的情況下想要導入，首先第一件很重要的事情其實是 『工具』。尤其是使用統一的工具，那麼就上面四個階段的部分先就工具做討論。

需求 :

Issue Tracking System，這邊泛指的是團隊內有沒有一個統一管理需求清單的地方，例如常見的JIRA、Asana、或者是開源的Redmine都是相當良好的管理需求的工具。再來是溝通工具，我們是不是需要一個溝通的工具，透過這個工具，可以即時的通知各個團隊內每個人目前現在的狀態，我們常見的像是使用Slack、DingTalk等等，一些好用的溝通工具，也可以讓我們在各個階段都可以收到一些自動化通知。

研發 :

在研發的部分，首先我們大家需要一套共同的代碼協作平台，常見的有gitHub、gitLab等等，這邊不做詳述，然後我們可能會需要一些代碼檢測工具，像是開發iOS，如果用的是Swift，我們會有一個Swift Lint去規範開發人員的Coding Style等。之後是代碼審核，為了提高軟體品質，我們需要透過Code Review去確保代碼的可讀性、穩固性等等，所以我們會有gerrit等Code Review的Tool，當然像gitHub或者gitLab本身也具備這樣的功能，之後我們還需要像是Jenkins、gitLab-CI這樣的CI/CD服務平台幫我們做自動化的建置與流程控制。

測試 :

在測試的部分，我們可以透過上述提到的Jenkins、gitLab-CI等相關CI/CD服務平台觸發我們的自動化測試的工作，在自動化測試的部分可能涉及了很多測試化框架選擇，然後還有一些測試報告的產出服務，當然還有關於代碼的靜態檢測，我們可以使用像SonarQube這樣的平台去分析代碼的質量。當然除了自動化測試之外，我們也需要一個Bug Tracking System，在一開始提到的JIRA、Redmine幾乎都具備了這樣的功能。

交付 :

之後便是交付及部署，這邊根據不同的平台(iOS/Android、後端、前端)會有不同的產出物，重要的是如何提供一個方便以及一致性的交付方式，去減少人工交付或者部署所產生的錯誤，所以我們可能會使用Docker建置一套可部署的環境，也可能透過像是Fabric這樣的App交付平台，讓我們的產出物可以自動上傳至平台並讓所有的測試人員以及產品人員可以拿到。

小結

透過上述的幾個流程可以發現，工具只是一個最初步的開始方式，當你有了這些工具的導入，才能往後去思考後續的各步流程，例如git flow應該怎樣設計，交付以及部署要怎麼能夠有dev、staging、production環境的不同環境的區分，自動化測試導入之後應該寫多少的單元測試，這些每一個都是相當大的議題與討論，也會因為團隊的不同而有不同的策略，但是只有透過漸進式的方式，慢慢導入這些工具，漸漸優化自己的CI/CD流程，才能開始有相對穩健的軟體品質。這邊附上一張導入CI/CD之後的開發流程圖。