五分鐘了解 CI

很久以前,曾經有寫過一篇文章,標題是我所知道的 DevOps,實際上裡面的內容是在講自己對 CI 與 CD 的了解。

剛好最近準備了一門課程是讓開發人員了解 CI 基礎,這篇文章是份簡單的筆記。

Continuous Integration(CI)

中譯是持續整合。這是由兩個單字組合而成,首先整合(Integration)的意思,是指把兩個東西摻在一起看能不能動。比方說,把程式放到環境裡試看看能不能正常運作,對於開發人員來說,最常接觸同時也是大家有聽過的整合正是「軟體測試」;持續(Continuous)則有一直、不斷地做的意思。

因此對開發人員來說:

持續整合 = 常常做測試

為什麼要做 CI

對寫程式的工程師來說,時間是最昂貴的成本。若定義一個 bug 被發現到修復完成的時間,稱之為「修 Bug 的成本」的話,我們再加入一個回饋週期(feedback cycle),即可畫出像下面這張圖:

圖片來源:http://www.agilemodeling.com/essays/costOfChange.htm

我們可以發現週期最短,修復成本是最小的;相對週期越長,修復成本就越高。舉兩個對應的例子:

  1. 寫程式在測試當下發現 bug,因此可以馬上修復,修復成本極小。
  2. 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。