五分鐘了解 CI
很久以前，曾經有寫過一篇文章，標題是我所知道的 DevOps，實際上裡面的內容是在講自己對 CI 與 CD 的了解。
剛好最近準備了一門課程是讓開發人員了解 CI 基礎，這篇文章是份簡單的筆記。
Continuous Integration（CI）
中譯是持續整合。這是由兩個單字組合而成，首先整合（Integration）的意思，是指把兩個東西摻在一起看能不能動。比方說，把程式放到環境裡試看看能不能正常運作，對於開發人員來說，最常接觸同時也是大家有聽過的整合正是「軟體測試」；持續（Continuous）則有一直、不斷地做的意思。
因此對開發人員來說：
持續整合 = 常常做測試
為什麼要做 CI
對寫程式的工程師來說，時間是最昂貴的成本。若定義一個 bug 被發現到修復完成的時間，稱之為「修 Bug 的成本」的話，我們再加入一個回饋週期（feedback cycle），即可畫出像下面這張圖：
我們可以發現週期最短，修復成本是最小的；相對週期越長，修復成本就越高。舉兩個對應的例子：
- 寫程式在測試當下發現 bug，因此可以馬上修復，修復成本極小。
- PM 或客戶發現 bug 後回報，通常都要查非常久才有辦法找到問題，同時極有可能要花很久的時間才能修復。
從圖中可以發現 CI 抓到 bug 是放在最左邊的位置，它是屬於週期短且成本小的情境，因此 CI 是有辦法降低修正 bug 的成本的，這也是最直接要做 CI 的理由。
開發人員應遵循的七項持續整合要領
Continuous Integration 書裡有提到七項要領如下：
1. Commit code frequently
時常提交程式碼
雖然前面提到「測試」是整合的其中一種形式，而提交程式碼則是整合的另一種形式－－整合程式碼，也就是合併（merge）程式碼與處理合併衝突（conflict）。
2. Don’t commit broken code
不要提交有問題的程式碼
開發人員要有基本的認知，程式碼必須寫好之後再提交。持續整合可以提早發現問題，再前進一步，如果打從一開始就不要把有問題的程式碼簽入版本庫，就會更完美了。
3. Fix broken builds immediately
立即修正壞掉的建置
只要發現了 bug，或是建置一遇到問題，就要馬上立即處理。一來是因為 bug 的特性都是放越久越難處理，因此早期發現解決的成本都很小（參考前面所提到的曲線圖）。另一個原因是要讓團隊理解 CI 建置是無法容忍錯誤發生的，只要容忍一次，後面就會有無數次的問題發生了（參考破窗效應）。
註：建置（build）泛指編譯（compilation）、測試（testing）、檢查（inspections）、部署（deployment）等。
4. Write automated developers tests
撰寫自動化測試
現代的軟體架構都非常大，使用自動化測試，能夠更有效的完成確認。
5. All tests and inspections must pass
所有測試與檢查必須要通過
要如何確認程式碼品質？當然是測試通過以及檢查通過。
6. Run private builds
執行本地建置
有辦法做本地建置，才有辦法在提交前確認程式碼是否有問題。
7. Avoid getting broken code
避免拿到有問題的程式碼
與「不要提交有問題的程式碼」相對的，我們不要有問題的程式碼，因為它馬上就會被修復，所以不具參考價值，不如先修復它之後再開始修改程式碼。
下一次將會來寫一篇五分鐘了解 CD。