技術棧管理：雲時代的研發環境

01-30

前文介紹了雲計算大背景對研發環境的影響。我們已經指出，現代IT組織應該把研發技術棧以PaaS的形式提供給開發人員，其中的要點是：

將標準的研發環境封裝為虛擬化、雲化的技術棧，由技術專家管理維護；
核心業務價值與技術支撐解耦，工程師專註於業務系統的開發；
自動化研發流程，降低研發管理成本。

如何實現這樣一個研發技術棧管理的平台？我們的觀點是，這樣一個平台應該集中管理組織中的技術棧，允許基於一個技術棧創建開發測試PaaS和生產PaaS兩個PaaS服務，從而支撐開發、測試、生產三種運行時環境。

一個平台

在一個典型的敏捷軟體開發場景（例如更具體的「用Java開發微服務」的場景）中，開發者需要頻繁地用到下列工具：

編程框架，提供基礎的結構與功能來支撐業務邏輯代碼，例如Spring Boot和Jersey。
版本控制工具，例如git。
依賴軟體，例如PostgreSQL資料庫。
自動測試工具，包括單元測試工具（TestNG）和功能測試工具（Concordion、Selenium）。
自動構建工具，Maven或Gradle。
持續集成工具，Jenkins或GoCD。

所有這些工具以及它們適當的組合與配置，我們把它稱為一個技術棧。我們上面的例子就是「Java微服務開發技術棧」，類似的，一個組織中還可以有「Java Web應用開發技術棧」、「H5前端開發技術棧」、「ReactNative移動應用開發技術棧」等等若干個技術棧。對於一般的IT組織而言，有限的幾種技術棧就可以覆蓋大部分軟體項目的形態。體量大如有數萬研發員工的某IT巨頭，提出的主要技術棧也只有十餘種。

在傳統的軟體開發團隊中，技術棧的組合與配置是由團隊的技術領導者負責的。在雲計算的大背景下，將基礎設施作為源代碼的思想再往前推一步，我們就會很自然地得出技術棧作為源代碼的想法：使用Docker和Ansible等技術，將技術棧的結構以源代碼的形式描述。在「基礎設施作為源代碼」的階段我們已經知道，以源代碼形式管理環境會帶來很多好處，例如更高的自動化程度、允許版本控制等。把技術棧作為源代碼以後，會帶來幾個重要的收益：

技術棧可以很容易地復用，因此可以把搭建技術棧的工作收攏到較少數技術領導者手中，研發團隊則只需在技術棧基礎上開發業務功能，降低了研發團隊的技能門檻。
最佳實踐可以被內嵌到技術棧中，並通過持續集成的形式對研發團隊形成約束，從而使研發改進舉措更容易推行。
縮短研發實踐的實驗和創新周期，可以對多個研發團隊開展受控對比實驗，團隊中自發產生的優秀實踐可以被快速抽取並固化到技術棧中。

技術棧管理平台作為組織級的研發管理載體，承載的是組織對研發團隊的引領和治理形式。在這個平台上，技術領導者會創建並維護技術棧，項目團隊則可以根據自己的需要選擇適合的技術棧，跳過大部分迭代0的技術準備工作，直接進入功能開發，並在整個產品生命周期中享受雲化開發環境帶來的收益。

兩個PaaS

基於已經定義好的技術棧，當項目團隊開始研發工作時，技術棧管理平台可以為他們創建兩個PaaS服務：一個是研發過程中使用的開發測試PaaS，另一個是真實上線用的生產PaaS。兩個PaaS的協作關係如下：

開發人員從開發測試PaaS中獲得一個開發環境，在這個環境中編寫代碼；
新編寫的代碼被提交到代碼庫中，後台的服務自動運行「提交門」測試，測試通過後，把代碼構建成可運行應用；
後台服務針對可運行應用自動運行「驗證門」測試，測試通過後，這個版本的可運行應用即被標記為可發布應用，並被存入構建產物倉庫；
測試人員針對通過了「驗證門」測試的可發布應用進行必要的手工驗證；
生產環境與開發/測試環境基於同一個技術棧（運行時環境上有具體的差別），開發測試PaaS中構建出的可運行應用可以直接部署到生產環境；
隨不同組織的發布流程不同，構建產物倉庫中的可發布應用可能直接（自動或手動）發布到生產環境，也可能被同步到生產PaaS的產品倉庫，以後再手動發布到生產環境。

可以注意到，這個流程、尤其是在開發測試PaaS中發生的流程，與Dave Farley在《一鍵發布》文中介紹的持續集成流水線非常相似。我們相信：持續集成對於現代軟體開發是如此重要，以至於它不應該以獨立的工具形式存在（因為這樣人們就有可能不用或者誤用）。持續集成應該被內建在軟體開發的工具和過程中，使它不被開發者注意、同時又不能被繞開——正如Spring內建了面向介面編程、IntelliJ IDEA內建了編譯和代碼格式檢查。

三個運行時環境

前面介紹的流水線已經暗示，在整個軟體交付周期中，存在三個不同的運行時環境。這三個運行時環境都有同樣的基礎，例如操作系統、依賴軟體等。同時它們也有一些重要的差異：

構建運行時：包含開發工具、構建工具和（可能是部分）測試工具，這是開發人員編寫代碼的主要環境——需要注意，「編寫代碼」在敏捷軟體開發的上下文中意味著「編寫代碼並頻繁進行提交門測試」，這是為什麼這個運行時環境中必須包含（至少部分）測試工具。
驗證運行時：包含全部測試工具及其他質量保障工具，這是對軟體質量進行全面驗證的主要環境。
應用運行時：包含運維工具，這是軟體真正運行的環境。這個運行時可能被應用於生產環境，也可能僅用在組織內部（例如UAT測試環境、培訓環境、demo環境等）。這個運行時中的依賴軟體（尤其是資料庫）也有可能被替換為環境之外獨立運行的軟體。

儘管為了支持不同環節的工作要求而有這些差異的存在，底線是：構建運行時構建出來的可運行應用，可以在驗證運行時中接受完整的驗證，也可以被部署到應用運行時正常運行。這與持續交付中「製成件流過整個流水線」（而非在各個構建步驟中分別生成製成件）的理念是一致的。

製成件的形式
在前文中我們已經提到：軟體包是一種對雲環境不友好的交付形式，理想的研發交付物應該是容器鏡像（很可能是一組彼此連接的容器鏡像），可以在雲上直接運行。Docker等容器技術使我們可以把所有軟體（不論背後使用什麼編程語言、實現什麼功能）都抽象為「IP地址+埠」的服務；再加上例如Docker Swarm或Kubernetes之類集群工具的支持，更可以把服務進一步簡化為一個埠。於是，技術棧管理的基礎設施可以得到更大程度的復用：不同的技術棧（不管編程平台是Java、NodeJS還是Python）構建出的應用都是一個（或一組）Docker鏡像，從而將「產物的形態」與「生產流程的結構」解耦。

小結

針對前文提出的雲計算大背景下對軟體研發提出的挑戰，本文提議了一種解決方案：技術棧管理平台。通過實施技術棧管理平台，為研發團隊提供開發測試PaaS和生產PaaS兩個PaaS服務、構建/驗證/應用三個運行時環境，研發組織能夠將技術棧的搭建和管理與業務系統的研發解耦，從而降低研發團隊技能門檻、快速有效地推廣研發最佳實踐、使研發過程中的技術與流程實驗和創新成為可能。