技術棧管理與雲時代的持續集成

02-04

在剛剛發布的第16期技術雷達中，我們看到ThoughtWorks在「技術」象限里旗幟鮮明地列舉了幾項與持續集成相關的反模式。這些存在多年的實踐和現象被放在了「暫緩」一環中，意味著ThoughtWorks正式向我們的客戶指出：如果你的組織仍在這樣實施持續集成，我們認為你應該考慮改變了。那麼，這些被批評的點背後映射出哪些問題，基於技術棧管理的雲時代研發環境又能帶來什麼新的思路？我們一起來深入分析。

持續集成的反模式

最需要被點名批評的現象莫過於「持續集成劇場」了：

很多開發者只是簡單的搭建了持續集成伺服器就以為在做「持續集成」，但他們實際上會遺失持續集成的關鍵優點而導致失敗。常見的失敗模式包括：雖然在一個共享的主分支上運行持續集成，但是代碼提交不頻繁，所以集成並沒有真正的「持續」。以及在一個測試覆蓋率不足，甚至是長期狀態為紅的情況下進行構建；或者在功能分支上運行持續集成，這會導致持續隔離。

簡而言之，這些團隊並沒有真正體會到持續集成的好處，而是為了完成上級的任務而演一場「我們在持續集成」的戲——這也正是這個反模式的名字由來。過去十年中，我們在眾多剛開始實施持續集成的企業見過這一幕。領導認識到持續集成的好處，但是推行成了個大問題：推輕了，下麵糰隊不願動，技術問題解決不了；推重了，下麵糰隊來個上有政策下有對策，領導想看什麼就給你演什麼——持續集成劇場就此落成。比如說你見過一個表面看起來一直是綠色但是背後連編譯都不敢跑的持續集成嗎？我見過。真是一場好戲。

為了解決持續集成演戲的問題，一些規模較大的企業開始建設持續集成中心。想法很符合直覺：既然團隊自己做持續集成有技術困難、還有可能變成演戲，那麼我就組建一支團隊專門幫他們一個個把持續集成跑通、幫他們管理持續集成伺服器，持續集成的運行和統計數據都在這個中央團隊手裡，下面的團隊總沒辦法演戲了吧？於是，他們又遭遇了第二個持續集成反模式：「所有團隊共用一個持續集成實例」。

那些必須使用中心化持續集成伺服器的交付團隊，常常依賴中心的團隊去完成小的配置任務，或者在共享的基礎設置和工具中排查問題，這給他們在進度上帶來長時間的滯後。

這次是康威定律帶來的困難：如果每個團隊使用的技術棧配置不同、技術棧配置和管理的職責仍然在每個團隊中，那麼技術棧演進與持續集成的演進就難免出現節拍不一致。於是管理著持續集成中心的中央團隊開始疲於奔命，幫一個個項目團隊修持續集成，而項目團隊還感到沒有得到足夠的支持。

第三個反模式是「企業級集成測試環境」，這也是很多組織建設持續集成中心的初衷之一：由於能執行完整端到端測試的環境稀缺，各個團隊的集成測試無論如何也必須在一個瓶頸處統一調度，所以中心化管理持續集成也就順理成章。然而，

這些企業集成測試環境通常稱為 SIT 或預生產環境）是當下持續交付常見的瓶頸。環境本身很脆弱而且維護成本很高，而這些環境通常存在一些需要由單獨的環境管理團隊手動配置的組件。在預生產環境的測試給出的反饋慢且不可靠，而且會重複測試那些在隔離的組件上已經測過的功能。

雲時代的新思考

技術雷達中批評的這些持續集成的反模式，是過去的時代背景造就的。尤其是以下幾點約束條件，造成了今天我們看到的持續集成的形態（以及長久以來存在的挑戰）：

計算資源短缺。這個約束條件決定了完整的、與生產環境相似的、能執行端到端驗證的環境必定是稀缺品，因此一個組織中多個團隊的集成必定會受限於某個瓶頸，或是企業級集成測試環境、或是持續集成中心。
計算環境沒有彈性。不僅硬體資源短缺，而且環境的開通、配置和管理很麻煩，所以團隊會調整自己的技術實踐去適應已有的環境，而這個調整的動作主要由團隊內的技術領導者來執行。其結果是即便多個團隊開發的軟體在技術棧上非常相似，他們的持續集成實踐也可能相當不同，在技術能力不足的團隊就會變成持續集成劇場。
版本控制工具的局限性。Subversion（以及其他更早的版本控制工具）在pre-commit階段通過伺服器端回調鉤子很難——如果不是完全不可能的話——得到完整的「提交後版本」，因此svn的pre-commit鉤子基本只能用於檢查提交信息是否符合規範，完整的驗證則必須在代碼已經合入代碼庫之後才能——在一台獨立的「持續集成伺服器」上——進行，而此時如果構建失敗就會阻塞整個團隊的工作。這也導致更多的團隊傾向於放鬆持續集成的要求、甚至淪落成持續集成劇場。

而這幾個約束條件在今天的時代背景下已經不復存在：計算資源仍然不能說極大豐富，但企業應用開發所需的x86架構計算資源在雲環境下已經不再短缺；在IaaS的基礎上，技術棧管理的PaaS提供了計算環境的彈性，使用相同技術棧的多個團隊可以輕易地獲得完全一樣的環境，因此團隊也可以採用標準的技術實踐，而不必為了將就手邊的環境而調整實踐。而git對svn的全面取代尤為值得玩味：由於可以在pre-commit階段直接獲得完整的待提交快照、並在這個版本基礎上執行測試，不符合持續集成要求的代碼將直接被拒絕提交——而不是在提交後才把問題暴露出來。於是，以下兩個要素的結合：

每個開發人員（以及自動構建jia都可以在PaaS雲上獲得完整的技術棧運行時環境；以及，
pre-commit階段可以對待提交的代碼進行完整的構建

將帶來兩個重要的影響。首先，持續集成不再需要一個「伺服器」。從它發展的早期開始，持續集成這個概念就一直與各種「持續集成伺服器」軟體工具緊密關聯：從早期的CruiseControl、Bamboo到後來的Jenkins、GoCD，以及雲上提供服務的TravisCI、SnapCI，持續集成中的「集成」這個動作一直發生在代碼已經提交之後、發生在一個團隊共有的伺服器上。而現在，持續集成可以在代碼提交之前發生、在一個從PaaS雲上彈性生成的環境中發生。

這個技術性的改變帶來的組織性改變將有著重要的意義：保證持續集成通過將會徹底變成每個開發人員自己的責任，沒有折扣可打，沒有其他地方可以推卸責任——現在構建不通過不會阻礙其他人提交代碼了，只有這個開發人員自己不能提交代碼。由此，持續集成將由一項團隊實踐變成一項個人實踐、由一項有較大妥協空間的實踐變成一項強制性的實踐。正如IntelliJ之類現代IDE把「通過編譯」這項要求變成了程序員感知不到的、而又不可妥協的質量要求，技術棧管理PaaS平台將把持續集成也變成程序員感知不到的、而又不可妥協的質量要求。

持續集成是如此重要，以至於我們不應該把它交給程序員自己去做。

在這樣的一個研發環境下，每個開發人員從寫下第一行代碼開始就必須遵循組織的質量規範，能夠被提交到團隊代碼庫的代碼都是通過了驗證流程、符合質量要求的。6年前當我構想這樣一個研發環境，我覺得它更像是一個遙遠的夢想。然而今天，支持這樣研發環境的技術棧管理PaaS平台已經被實現出來了。你需要的就是在你的研發雲上實施它。