在云計算的時代大背景下，我們推薦采用研發技術棧管理平臺來集中管理組織中的技術棧，允許基于一個技術棧創建開發測試PaaS和生產PaaS兩個PaaS服務，從而支撐開發、測試、生產三種運行時環境。通過三種運行時環境的區分，技術棧管理平臺實質上設置了一條標準的精益軟件生產流水線，為軟件研發生命周期中的三個核心工種——開發、測試、運維——布置了標準的“工位”。在實施技術棧管理平臺時，從這三個核心工種之中的任何一個切入，都可以優先建設該工種對應的工位，從而拉動整條云化生產流水線的實施。

從開發切入，打造規范的軟件開發底座

在數字化的大背景下，眾多IT組織都面臨技術能力短缺的境況。尤其是傳統企業的IT部門，需要用有限的研發專業技能交付越來越多、變化越來越頻繁的IT系統，還需要管理外包合作方的團隊，對于開發底座規范化的要求日益顯著。這些開發團隊常見的一些挑戰包括：

■技術實踐能力有限，不能保證每個項目采用業界最佳的框架與工具組合。

■開發流程不規范，代碼質量關注不夠，技術債累積嚴重。

■外包團隊管理乏力，對外包團隊的開發實踐缺乏約束。

實施技術棧管理平臺以后，整個組織可以識別并聚焦幾種具有普遍代表性的軟件形態（例如“Java微服務”、“Java Web應用”、“安卓移動應用”等），集中技術骨干力量，搭建項目基礎架構，以技術棧的形式固化下來。開發團隊要啟動一個項目時，只需要從技術棧管理的PaaS平臺上選擇自己需要的技術棧，就可以立即生成自己的構建運行時，其中包括代碼倉庫、應用基礎框架、依賴軟件、自動化構建工具等。基于這個構建運行時，開發團隊可以基于已經搭好的腳手架立即開始編寫代碼，并在PaaS云上進行基本的驗證，然后提交到團隊代碼倉庫。團隊的技術領導者不需要考慮開發環境應該如何配置，開發人員也不需要在自己的電腦上做任何環境準備工作，從而極大地降低了項目啟動的技術門檻。

作為對開發工位的規范要求，技術棧中會規定“提交門”的質量標準，達不到質量標準的代碼將無法提交到團隊代碼庫中。這個實踐與持續集成一樣，都是源自豐田生產方式的“安燈”實踐：如果出現質量隱患，應該立即停線修復，而不是讓帶著質量隱患的生產線繼續運轉。在一般的開發團隊中，提交門的質量標準至少包括（1）代碼能通過編譯；（2）代碼能通過靜態質量檢查。通過引入代碼復雜度、代碼規范性檢查等基本質量標準，能促使開發團隊關注代碼質量，避免基本的技術債不斷累積。水平較高的團隊會在提交門中包含單元測試，單元測試不通過、或單元測試覆蓋率達不到標準的代碼將無法提交。

如果需要引入外包團隊來協助開發，外包團隊可以直接從技術棧管理PaaS服務商獲得自己的構建運行時，絕大部分的開發規范可以用提交門驗證的形式來承載，從而將組織的質量要求固化到開發環境中，降低規范化管理外包團隊的難度和成本。

從測試切入，建立云測試平臺

在數字化、互聯網化的IT大背景下，軟件系統上線的周期不斷縮短，兩周一迭代已經成為眾多團隊的標準配置，一些創新型業務已經要求將上線周期縮短到一周、幾天、甚至一天幾次。不斷縮短的上線周期，使很多IT組織在測試方面的問題暴露出來：

■測試自動化程度低，手工回歸測試跟不上頻繁上線的節奏。

■測試環境爭用，環境管理工作量大。

■性能、安全等非功能性需求的測試投入不足，到項目晚期才開始測試。

如果這些問題是一個組織當前最大的痛點，技術棧管理平臺的實施也可以從測試工位開始入手，為整個組織打下堅實的質量保障基礎。測試和開發的技術骨干可以一同選擇適宜的自動化測試工具，將其連接配置好，準備好自動化測試的腳手架，打包到技術棧的驗證運行時中。測試人員只需按照業務需求編寫自動化測試例，并放在技術棧中規定的“驗證門”環節自動執行。當系統最重要的功能都能被自動化測試覆蓋，測試人員就能從繁重的手工回歸測試中解脫。

自動化測試需要可靠且可復制的測試環境來執行，這正是云計算的優勢所在。在技術棧管理PaaS中定義了測試運行時環境后，每當測試人員或自動化的驗證門要執行自動化測試例時，就會從云中取出一個測試運行時，其中除了被測系統的依賴軟件外，還包含了配置好的各種測試工具。被測系統會被加載到測試運行時環境中，執行自動化測試例，收集測試報告，然后測試運行時環境就會被銷毀回收。整個過程中不需要測試人員手工管理測試環境，也不需要與其他測試或開發人員共用一套環境。

一旦測試人員不用“人肉回歸”大部分軟件功能，他們就可以把更多的精力投入非功能性測試。性能測試、安全性測試等非功能性測試所需的工具集同樣可以被內建在技術棧中，方便測試人員日常工作。同時，測試人員還可以把非功能性測試編寫成自動化的測試例，將其加入驗證門的測試集，從而使非功能性需求也持續得到保障，以免在項目晚期才發現重大性能或安全問題。

從運維切入，構建高響應運維能力

同樣，數字化、互聯網化的大背景也對運維團隊提出了新的挑戰。從業務客戶的角度，他們不僅希望自己的需求能盡快上線被用戶使用，而且還希望及時獲得來自用戶的反饋，幫助他們做出調整。在一些領先的企業，運維更是能支持業務客戶針對真實用戶進行快速的受控實驗，從而驗證自己的業務假設。在這些新的要求下，很多IT組織的運維團隊暴露出了能力上的不足：

■運維自動化程度低，需要大量手工操作，工作量大，可靠性低，容易出錯。

■系統監控不完備，出現故障時不能及時發現和快速排錯。

■生產系統的信息不能快速轉換成業務洞見，無法支持頻繁的線上受控實驗。

技術棧管理平臺的實施同樣可以從運維工位入手，以打造高效的DevOps體系為優先目標。

你說的是哪種DevOps？

由于歷史原因，如今大家在談起“DevOps”這個詞時，其中包含的可能是三重相關但不同的含義：

1、如何借助基礎設施即服務、運維自動化等手段，加快代碼部署到生產環境的速度。

2、如何借助日志和監控手段，及時把生產環境的情況反饋到開發團隊。

3、如何借助端到端的埋點、數據采集、分析和可視化，把用戶行為反饋到業務。

以運維視角優先切入時，技術棧的建設就自然地偏向運維工具。在支持計算資源彈性分配的IaaS層（例如基于ScaleWorks的私有云）之上，將自動化配置管理工具（例如Chef、Puppet、Ansible）及其他常用的運維工具打包在應用運行時中，運維人員可以隨時從技術棧管理的PaaS服務中獲得完整且配置好的應用運行時，再從通過了測試驗證（可能是手工驗證）的發布候選鏡像中選擇一個版本放入應用運行時，即可快速完成應用的部署上線。生產環境的配置以代碼形式記錄，可以由技術能力較強的DevOps團隊專門維護，從而省去了大多數運維人員手動管理運行時環境的工作量與風險。

在應用運行時環境中，可以根據軟件系統的特征預先配置好日志工具（例如ELK、Splunk）和服務指標監控工具（例如Collectd），使開發團隊無需額外工作就能獲得豐富有用的生產環境信息。一些水平更高的團隊會在應用運行時環境中設置更智能化的運維功能（例如基于Hystrix的服務熔斷機制），使運維更具響應力。

應用運行時環境中還可以植入端到端綜合語義監控所需的工具設置，從而支持對業務場景埋點和分析，甚至是結合流量路由技術進行受控實驗，用數據為業務決策提供支撐。業務有了縮短反饋周期的訴求，運維有了快速響應變化的能力，兩端夾擊可以倒逼研發環節提升響應力、縮短交付周期，這也是研發組織變革的一個套路。

小結

技術棧管理平臺的目標是為現代IT組織創造云環境下的精益軟件生產流水線。但對于很多組織而言，這條流水線并非一步到位，而是一個分階段建設的過程。在這條流水線上，開發－測試－運維三個核心工位都可以成為實施技術棧管理的切入點。從組織當前最顯著的痛點出發，選擇一個工位開始實施云化的技術棧管理平臺，并依循瓶頸理論拉動其他工位的逐步改進，這對于眾多不以IT能力見長的組織而言，是一條可行的云化、數字化道路。