理解 CI 與 CD 間的差異

[ChaoLiou]

這篇算是很基礎的 CI/CD 概念文章, 文中從世面上的工具或平台中跳脫, 說明了其實 CI/CD 就只是開發方式, 而各家所運用與闡述會有些微不同罷了.

[name=Chaol Liu][time=20180912]
derived from...

Understanding the Difference Between CI and CD

thenewstack.io

[name=Kostis Kapelonis][time=Wed, 05 Sep 2018 16:00:24 GMT]

---

• 網路上有非常多 Continuous Integration(CI, 持續整合) 和 Continuous Delivery(CD, 持續交付) 相關資訊. 很多 blog 發文嘗試要以技術層面去解釋這些 methodology(方法論) 是做甚麼, 以及如何協助你. 不幸的是, 大部分情況, 這兩種 methodology 通常都與特定工具或供應商有關. 公司內常見對談的情境可能是:
  1. 你在團隊裡有使用 CI 嗎?
  2. 當然有, 我們用 X 工具
• 事實上, Continuous Integration & Delivery 都是 development approach(開發方式). 不會與特定的工具或供應商有關連. 雖然這些工具和 solution 能協助你完成 CI/CD, 但其實只靠 bash script 和 Perl one-liner 就夠.(聽起來不實際, 但卻是可行的)
• 所以, 不要以使用甚麼工具和其他術語來解釋 CI/CD.

軟體 integration 的黑暗時代

• 有一間公司 SoftwareCo Inc., 裡面員工有 Alice, Bob, Charlie, David 和 Elizabeth, 公司產品是一個應用程式, 叫 SuperBigProject. Alice, Bob 和 Charlie 是 developer. David 是 test engineer. Elizabeth 則是團隊的 project manager.
• 傳統的開發方式會是以下:
• Alice, Bob 和 Charlie 各自處理三個不同的新 feature. 每個 developer 都會以個人習慣 coding 與 testing. 而且都使用 long-running feature branch 模式(意旨會是大 feature, 而且 feature branch 從建立到完成都不會 merge), branch 會存在好幾個禮拜, 甚至好幾個月, 最後才被 merge 到 production.

• 某天, Elizabeth(PM) 把整個團隊聚集起來, 然後宣布: "各位, 我們需要 release 新版本. 請各位想辦法弄出來"
• 這時, Alice, Bob 和 Charlie 拼了命要把三個 feature branch integrate 到同一個 branch. 當時情況緊急, 因為這些 feature 都沒放在一起測試過. 很多 bug 慢慢浮現出來, 因為當初 wrong assumption 或是環境問題造成(還記得剛剛所說, 所有 feature 都在各自獨立環境裡測試).
• 當時辰接近時, merge 完成的結果會交給了 David, 他會接手處理額外的手續, 以及自動化測試. 這期間也會很耗時, 而且他是能批准或擋下 release 的人, 他會依據找出多少很嚴重的 bug 而決定. 當 David 進行測試時, 所有人都會看著他, 因為他的測試結果如何, 就能說明會有多少問題, 也代表會延誤 release 多久.
• 最後測試完成, Elizabeth 開心宣布: 這次的版本準備要 package, 然後再交給客戶.
• 所以大家從這篇虛構的故事裡感覺如何(但現實幾乎都會發生)?
  1. Alice, Bob 和 Charlie (development) 並不開心, 因為他們總覺得在 release 前都要處理很多 integration 問題.
  2. David(testing) 並不開心, 因為他的工作很不平衡. 一開始 peaceful period, 在等工程師完成 feature. 然後就被工作淹沒了, 必須處理各種非預期的測試情境, 而且所有人都會緊盯著他.
  3. Elizabeth(manager) 也不開心. integration 階段會是專案最艱難的過程. 當時非常緊急, 許多沒預期到的問題還蜂擁而上. Elizabeth 夢想有一天 release 不會出狀況, 但始終沒如願. 評估專案的 integration period 真的永遠都是一場 guessing game.
• 團隊所有人都不開心.(順帶一提, 如果你的公司還是像這樣開發軟體, 請思考一下, 如此的開發流程會不會對團隊的情緒造成傷害.)
• 主要的問題是每次產品 release 都出現 single integration. 這是流程中的 paint point, 應該避免, 並想辦法要讓團隊 release 能毫無壓力完成.

將 "continuous" 加進 integration

• 現在我們知道 Integration(整合) 的意思, 那就很容易理解何謂Continuous Integration(持續整合). 有一句諺語說, "如果有件事只做一次很痛苦, 那就經常做淡化它." CI 本質上就是重複做 integration 階段所做的事情, 以頻繁 integration 來緩和痛苦. 最顯而易見的方式就是每次 feature merge 完, 都做一次 integration(而不是等到要 release 才做).

• 當團隊實施了 CI
  1. 所有 feature 會直接 merge 到 master.
  2. developer 不會各自做自己的 branch. 所有 feature 都會從 master 上開發.
  3. 如果 master 在獨立環境健康, 就會認定 feature 已完成
  4. 包括 feature 和 master 都會自動做測試
• CI 會是更好的軟體開發方式, 因為:
  1. 降低 feature merge 出狀況的數量
  2. 解決 "可是在我的電腦運作正常阿" 的疑問
  3. 將整個 testing period 切成許多 period, 每個 feature 會逐漸 merge 到主線(而不是一次就 merge 全部).
• 結果證明, 運用 CI 的團隊不會活得像坐雲霄飛車一樣(開發是冷靜期, 接著壓迫你 release), 而是以漸進的方式慢慢將專案完成.

軟體 delivery 的黑暗時代

• 現在我們看完 integration 的歷史, 以及 Continuous Integration 的運作模式, 可以往下一層 Continuous Delivery 邁進.

• 實施一次 release 本質上算是重大事件. 軟體測試完, 另一個人會被指派 package 與 deployment 的工作. 要 deliver 軟體到 production 也會是一段壓力期, 傳統上會涉及許多手動操作(與許多檢查事項).
• 不太常會發生 deployment(有些公司六個月才 deliver 一次). 極端案例, 甚至只發生一次(若使用 waterfall design approach(瀑布式設計方法)).
• 快到 deadline 才 deliver 軟體, 會與不經常 integration 所發生相同的問題:
  1. production 環境通常發現與測試環境不同, 需要做額外設定.
  2. 在測試環境運作正常, 一到 production 環境卻壞.
  3. release 有未完善的功能, 要麼關掉功能, 別給客戶, 要麼就延期 release.
  4. release 會讓 developer(想要 deliver 新功能) 與 operation(想要穩定性, 不想一次 deliver 太多新功能) 兩者間產生緊張氛圍.
• 你應該能夠看出這裡的模式. 如果我們透過頻繁的 integration 能減緩痛苦, 那 delivery 也能如此.

將 "continuous" 加進 delivery

• CD 會盡可能頻繁實施軟體的 packaging 與 preparing(就像送上生產線一樣). 最極端是每次 feature merge 都 deliver.(先 CI, 緊接著 CD)

• 因此, CD 比 CI 做的事情又更多一些. 每次 feature merge 到 master, 程式不只會測試其正確性, 也會 package 並 delpoy 進測試環境(理想是要與 production 環境一致). 所有事情都會自動發生.
• 每個新的 feature 都有機會推進 production, 都是有潛力的 candidate(候選者). 但不是所有 candidate 都會進 production. 會依據團隊內的考量, 人為介入決定是否 deploy. 我們只要決定 release 該不該進 production 即可(但不用做 prepare release). release 早已 package, test 並且 deploy 到測試環境了.
• CD 會比 CI 更不易採用. 原因是每次的 release candidate 都有可能會進 production, 也可能不會, 你還要將完整的 lifecycle 做成全自動化:
  1. build 應該是 repeatable(可重複) 與 deterministic(決定性).
  2. 所有 release 步驟應該要自動化.
  3. 所有設定和其他相關檔案都要放在 source control 裡(並不只有 source code).
  4. 每個 feature/release 應該要在測試環境中測試通過(理想的測試環境是要能動態建立, 與動態銷毀)
  5. 所有測試組合應該要自動化, 而且要很迅速就完成.
• 雖然 雲端 能協助我們達成所有需求, 但在軟體團隊裡(包含 developer 與 operation) 都還是要某種程度的紀律才能真正擁抱 CD.
• 一旦 CD 到位, release 會變得微不足道, 因為只要一個按鍵就能執行. 每個人(不只是 PM) 都能親眼目睹現在的 release candidate. 目前的 release candidate 或許不會有所有要求的功能, 或可能尚未滿足所有需求, 但直到真正關注 release 之前, release candidate 都不太重要. 重要的事情是 release 會完整做過 test 與 package, 再準備送到 production(如果需要的話). 任何專案關係人應該要給它綠燈, 然後立即將 release 移至 production.
• 如果你有使用 CD, 軟體的 lifecycle 會是以下:

• 每個 release candidate 總會預先準備好. 再經由人為決定 release candidate 是否要推進 production. 不會進到 production 的 release candidate 仍會以 artifact 儲存著, 等到未來需要時使用.

加碼: Continuout Deployment

• CD 的 D 也可代表成 deployment. development approach 會建立在 Continuous Delivery 之上, 而且完全移除掉所有人為介入. 任何準備好的 release candidate(通過所有品質測試關卡) 立刻就會推到 production.

• 只有少數公司會這樣做. 不靠人為操作, 直推 production, 但不該輕易採用這種方式, 不過有許多公司甚至連 Continuous Delivery 都沒有實施, 更不用說 Deployment.

• 你的團隊應該要確認每一層基礎都夠扎實, 才能往上層走.
• 用另一種方法是透過下圖, 觀察這些 methodology 所涵蓋的範圍, 與 CD 對於 CI 的需求如何:

• 確認有以正確的順序, 依循每個開發圖表推進. 把目標設定為 CD 會比較實際, 而且支援 CD 的工具也較豐富.

[MagicJohnJang]

好文. 👍

PS. got typo: 如果 "master" 在獨立環境健康