持續整合 2.0

根據「百度百科」的定義

持續整合是一種軟體開發實踐，即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建（包括編譯，釋出，自動化測試）來驗證，從而儘早地發現整合錯誤。

重點

編輯 → 釋出 → 自動化測試
常見的 CI 軟體工具或平臺主要覆蓋這三個階段

變化

如今敏捷開發的「興起」，很大程度上對於持續整合這個模式提出了更高的要求，倘若仍舊停留在 編譯、釋出、自動化驗證 這三個階段，對於敏捷而言，只是做到了 區域性 敏捷，而不是專案/產品敏捷。

因此，要達到真正的 專案/產品敏捷 ，至少要包含以下幾階段:

需求管理 → 編碼 → 單元測試 → 程式碼掃描 → 編譯 → 釋出 → 自動化測試 → 質量評估

解決方案

有人期望用 JIRA/禪道 這樣的工具來完成 需求、缺陷、測試用例 的集中式管理，只能說效果一般般，並且 TA 無法解決全階段的覆蓋。

有人期望用 Jenkins 這樣的工具來完成 單元測試、程式碼掃描、編譯、釋出、自動化測試，但 TA 完成的只是持續整合中的很小的幾個階段，不用覺得包含了 5 個階段，就獲得了整個 CI，其實差得還很遠。

技術層面能解決的，一定是金字塔的最底層。

金字塔中端和頂端的那些，很大程度上僅靠技術是無法解決的，更多的需要經驗的傳承。

把經驗抽象成解決方案，是 持續整合 2.0 的突破點。

拋開工具看本質，當我們不再依賴工具，思考如何徒手解決這些階段，可能會有不一樣的收貨。

很多 DevOps 平臺對於業務而言，比 Jenkins 的流水線更友好，有些加入了組織許可權流程的設計，使其不僅僅是個 CI 工具，但仍舊無法覆蓋 持續整合 2.0 的所有階段。即使現在已有的平臺都覆蓋全了，也未必實現真正的 持續整合 2.0，因為TA們只提供了技術的解決方案。

而真正的 持續整合 2.0 需要提供一個會思考、會判斷的指導。