For more, please visit my GitHub repo: github.com/kingcos/Per…
Preface
一個軟體工程專案從編寫、到測試、再最終交付到使用者通常有很多重複且固定的步驟。雖然作為開發者，我們的核心任務是編寫程式碼，而這些其他的步驟卻也不能忽視，持續整合（Continuous Integration）則可以幫助開發者完成這些瑣碎的事務，提升團隊的開發效率與質量。
本文將主要介紹持續整合是什麼，以及其中的好處。當然，您可能也注意到了標題後面「（一）」，沒錯，持續整合並非一篇文章可以概括，筆者希望儘可能將目前團隊中使用到的和持續整合相關的內容進行總結，目的是為了讓大家一起思考如何讓持續整合更好地服務我們開發。當然，限於筆者能力，文中不免出現遺漏，也望讀者能夠批評和指出。
What
持續整合，譯自 Continuous Integration，簡稱 CI（在下文中，將統一使用該英文簡稱）。在 Wikipedia 中，也有針對 CI 特別詳細且專業的介紹。簡而言之，當開發者通過版本控制系統（例如 Git）提交了程式碼，CI 系統將為其自動執行構建、分析、測試等服務，當前面的服務一致通過，其也能直接將產品部署到生產環境，而後進入下一個迴圈。其中每一步都將自動觸發、執行，結果也將會自動反饋回開發者。正如下圖所示，CI 的重點在於 C——持續。
Why & Why not
那麼為什麼需要 CI 呢？相比於傳統的先開發，再測試，後上線的模式有哪些好處呢？在團隊使用 CI 這段時間中，得出了以下主要兩個好處：
- 及時發現錯誤。CI 並不能消除錯誤，但 CI 將發現錯誤的時機儘可能地提前，所以也更加節省時間來改正錯誤。當開發者提交程式碼至程式碼倉庫時，其對於程式碼的熟悉程度是最高的。如果這個時候儘可能的糾正一些錯誤或不當，開發者將能很快注意到並將錯誤改正，避免了由於時間或者團隊中其他人對於程式碼的修改所導致的問題，提升了開發效率。
- 自動化。市面上的 CI 平臺都給了開發者比較高的自由度，能夠執行指令碼或命令。因此很多自動化的操作都可以制定好，來自動化地執行，節省開發者的時間。
如果這兩個顯而易見的好處還不足以說服，可以參考文末 Reference 中 EKATERINA NOVOSELTSEVA 的文章。那麼 CI 會不會也存在什麼難處呢？
- 跨技術棧。CI 並不特定於前端或者後端，CI 通常根據不同的平臺而有很多不同，包括配置的方法、使用的語言、自由度等等。CI 又和 Docker 的發展有一定的關係，因此跨技術棧可能讓一些團隊望而卻步。不過好的是，DevOps（Development & Operations）也在國內漸漸興起，越來越被重視。
- 跨平臺。這裡所指的平臺是指程式碼託管平臺、CI 平臺、以及部署平臺。在公司開始時，可能並不能輕易考慮到後續的發展，因此在原有平臺加入 CI 可能需要跨平臺的協作。對於一些「黑盒」的平臺，有時便難以很好的整合。不過，現在 Git 的兩大平臺 GitHub 和 GitLab 都很重視且支援 CI 平臺，也便於開發者使用。
如果後面兩個問題並沒有阻撓你，那麼就開始嘗試 CI 吧～
How
CI 並不依賴於某種特定的技術棧，其屬於一種程式設計正規化。但是，具體談及如何實踐，這就需要結合不同的工具和業務，進行定製。
Jenkins
Jenkins 是一款使用 Java 開發且開源的持續整合工具，很多 iOS 團隊內部都會使用 Jenkins & Fastlane 來自動化打包。因為 Jenkins 是開源的，可以方便地部署在自己的伺服器中，而且也有很多外掛來輔助不同的技術棧和功能需求。Swift 官方也使用了 Jenkins 作為自己的 CI。
GitHub with Travis CI
GitHub，人盡皆知，是全球最大的程式碼託管平臺，但 GitHub 本身並沒有整合 CI。但有很多 CI 平臺為 GitHub 定製 CI 環境，其中使用較多的便是 Travis CI。在 GitHub 倉庫中看到有 .travis.yml 檔案便意味著該倉庫整合了 Travis CI。對於開源的專案，可以選擇它就不用開發者再單獨配置伺服器來運作 CI，當然速度可能會慢些。之前在寫個人的一個命令列工具時，便嘗試使用了 Travis CI，而且可以非常容易的將 CI 狀態和程式碼覆蓋率的 Budge 標示在專案文件中。
GitLab with CI
相比於上述的幾個平臺，GitLab 真正把程式碼託管和 CI 結合了起來，並在最新 Release 版中加入了 Auto DevOps，似乎是更加先進的 CI。團隊內部目前使用的便是 GitLab EE，後續就將以 GitLab 為主，講講其中配合 GitLab Runner 來規範化開發流程。