分析持續整合

  • 4 分鐘

持續整合是 DevOps 分類法八大功能的其中一個。

探索需要持續整合的原因

1999 年 9 月 23 日，火星氣候探測者號 (Mars Climate Orbiter) 裝載著太陽能板，希望在暫時降落至火星的上層大氣層時能受到保護。

如果成功進入軌道，衛星就能夠將火星的相片轉送到地球，且長達數年。 但可惜的是，飛行器在火星的大氣層中燒毀了。

由協力廠商提供的地面控制軟體發生錯誤，其以英制單位 (英磅-秒) 來計算值。 NASA 所建立的軟體則預期值會以公制單位 (牛頓-秒) 計算。 由於這些值未正確轉換，因此太空船位置的微小差異在數百萬英里的過程中變成嚴重差異。

品質保證部門並未注意到外部軟體中使用了英制單位，雖然當時 NASA 的編碼規範已明文規定應使用公制單位。 而且因為檔案格式錯誤和其他錯誤，計算也是以手動方式進行，而不是使用提供的軟體。 這種情況就是需要持續整合的範例。

探索持續整合

持續整合是一種思維和小組策略。 除此之外，身為作家和演說家的 Martin Fowler 說過，持續整合是一種軟體開發做法，小組成員需經常整合其工作，通常每一個人每天應至少整合一次 (因此每天會有多項整合)。

每項整合都會透過自動化組建進行驗證 (包括測試)，以儘快找出整合錯誤。

如果執行正確，此方法就會在程序中及早攔截問題，以降低整合問題的發生率。

圖表顯示持續傳遞和持續部署之間的差異。這兩者的階段都相同：程式碼完成 - 單元測試 - 整合 -接受測試 - 部署到生產環境。若為持續傳遞，部署到生產環境會手動進行。若為持續部署，則會自動進行。持續整合會橫跨持續傳遞和持續部署的前三個階段。

持續整合的目標：

注意

請注意持續整合目標包含持續共同作業、持續傳遞和持續品質的方式！

但是若沒有持續整合，會發生什麼事？ 缺乏持續整合的工作通常會導致：

  • 開發週期很長
    • 非編譯程式碼
    • 在任何時間點，原始程式碼都有可能無法運作
    • 程式碼凍結
  • 組建失敗/錯誤計數過高
    • 分支存留期很長，需要很多天來完成合併工作
    • 原始檔控制中缺少程式碼
    • 延遲發現開發週期中的安全性瑕疵
    • 大量的技術債務
    • 沒有程式碼涵蓋範圍數字或數字過低
    • 整體品質降低
  • 有限的通訊和共同作業
    • 程式碼未遵循編碼標準
    • 沒有程式碼檢閱或很少
    • 開發週期中的測試延遲完成
    • 如果有的話，很多都是以手動方式執行

整合點是用來改善系統的快速意見反應迴圈。 若錯失整合點的時機，專案就會發生問題。 以下是 Dantar Oosterwal 在＜精益機器 (The Lean Machine)＞一書中針對整合點所做的敘述：

整合點旨在控制軟體開發。 是改善系統的槓桿點。 若錯失整合點的時機，專案就會發生問題。

Dantar Oosterwal，＜精益機器＞

© Scaled Agile, Inc.

如果您想知道您的小組是否有確實執行持續整合，以下問題可協助您判斷答案。

  • 所有開發人員都採用主幹式 (trunk-based) 開發嗎？
  • 主幹上的每個變更都會啟動組建流程嗎？
  • 當組建和測試失敗時，小組是否會在幾分鐘內修正組建？

績效也會因為持續整合是否存在而受到影響。 Nicole Forsgren、Jez Humble 和 Gene Kim 合著的《The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations》一書所收集和分析的資料指出，績效低的業者加速上市時，品質會下降。

但績效較高者可以在維持品質的同時，加快進入市場的速度。 它們具有較短 (且較不復雜) 的部署週期，並使用持續整合來立即補救問題，進而提高流動性和效率。

2017 績效較高者 績效中等者 績效較低者
部署頻率 每天多次 1 週 - 1 個月 1 週 - 1 個月
變更的前置時間 <1 小時 1 週 - 1 個月 1 週 - 1 個月
MTTR <1 小時 < 1 天 1 天 - 1 週
變更失敗率 0-15% 0-15% 31-45%