【引言】
工程實踐，也有稱爲技術實踐，其推進在敏捷轉型當中具有重要位置，有推算認爲效能提升裏面的至少一半來自於工程實踐。由於不能嚴格的區分提升來自於哪裏，以上推算難以證實，但也可以體會到工程實踐的重要性。
當一位教練輔導10人團隊時，可以與團隊成員逐個結對，手把手傳遞，而在敏捷轉型在超過100人的情況下，工程實踐的推進就會遭遇規模化問題。而隨着敏捷DevOps的深入，當前1000人級別的推進已經有很多了，到了千人級規模，顯然逐個結對顯然推進速度不夠快，原先在10人團隊的推進手段很難複製到千人級。本文試圖來看看千人級工程實踐推進。以下來探討下工程實踐規模化的要點。
【技術教練團隊】
首先跟着上面例子，既然光靠1個技術教練逐個結對去推進顯然不夠，那麼很自然的有個方案是建設技術教練團隊和外圍熱情者，比如工程實踐主題的CoP，比如TDD CoP，持續集成CoP。但是這個方案在業界採納的比例不高，成建制的管理教練團隊比較多見，成建制的技術教練團隊相對很少，就算有，人數也有限。在規模化下工程實踐氛圍也許比有限的技術教練團隊更加重要，而千人級工程實踐氛圍的帶動得要有賴於組織刻意的推動，首選是持續集成。
【持續集成】
規模化工程實踐首選的推進點是持續集成。通過持續集成工具，天然可以方便地以組織級視角來觀察，也就是可以得到規模化展現和度量。比如可以看到哪些團隊或者系統已經啓用了CI（持續集成），具體樣例指標有：
- 每個月進行多少次，
- CI成功率如何，
- CI裏面的自動化測試用例數量，趨勢是否增長
- 測試覆蓋率趨勢如何。
另外持續集成是組合實踐，不同組織有不同側重點，而且在理論上與持續部署存在交叉。從規模化推進角度，試圖來識別持續集成裏哪些實踐更加優先。
【哪些實踐更加優先】
招行去年2019年公佈了其DevOps建設情況，裏面給出了招行成熟度模型，成熟度分三級：一級包含了自動化編譯、靜態代碼掃描、發佈製品庫三個工程實踐。二級是在一級的基礎上，增加了自動化部署。三級是在二級的基礎上增加了單元測試和自動化測試。（引用自招行滕樂英老師分享的演講實錄丨招商銀行DevOps實踐及DevOps標準認證評估分享）
筆者的歸納與招行此模型大體一致，按優先順序從高到低如下：
- 自動化編譯
- 靜態代碼掃描
- 發佈製品庫
- 自動化部署
- 自動化測試
自動化測試這裏與招行不一樣，下文會說明。
自動化編譯是理所當然的高優先，沒有這個餘下一切免談。
靜態代碼掃描是組織級容易推進的工程實踐，最典型的例子是安裝SonarQube服務，提供給各一線團隊使用。開始時可以降低門檻來切入，切實讓廣大一線團隊感受到好處，然後可以迅速鋪開，切實規模化的觀測到組織整體代碼質量情況。與此實踐對照的是人工code review，code review需要一線團隊主動的人工付出，其規模化推進就有較大困難，需要專項建設。
發佈製品庫爲發佈管理要點，確保投產版本準確並且可以回溯。
自動化部署在海量服務部署情況下顯然也是高優先。
【複雜的自動化測試】
然後來到了複雜的自動化測試。首先的複雜來自於自動化測試這個詞本身，自動化測試在不同組織語境下有不同含義，有些地方說的自動化測試是指啓用諸如selinium的自動化測試，招行把單元測試和自動化測試並列，看起來單元測試好像不是自動化測試。
本文采用其字面意思，即是覆蓋全部自動化測試，採用微軟的自動化測試分類方法，按如下劃分：
L0自動化測試
特徵是無需部署安裝也不依賴外部資源，這與經典單元測試高度重合。爲什麼不用單元測試這個提法？因爲有些地方的單元測試超出了L0範疇，甚至覆蓋到了L2，這與XUnit系列單元測試工具的強大有關，無論如何，單元測試這個詞目前存在不同理解，囉嗦一些的L0自動化測試更加精準。
L1自動化測試
特徵是無需部署安裝但依賴外部資源，也類似於單元測試，一般所用工具就是XUnit系列。
L2自動化測試
特徵是無UI界面基於接口/API的測試。仍然可以使用XUnit系列工具，當然也可以使用專門接口測試工具。
L3自動化測試
特徵是UI界面自動化測試。常見使用Selinium。
微軟公佈的實例裏面說明當前微軟目前現有大多數測試都是L3級，而招行的情況是接口測試佔據多數，招行精益敏捷類對接口測試覆蓋率要求達到100%，也就是在以上的L2級。
招行將其測試組合形容爲測試橄欖球型，這與筆者之前所提出的紡錘形是一回事。
對於微軟實例說L3最多，這也許與微軟產品特徵有關，尤其是其Office系列，這樣的話是冰淇淋形。筆者猜想微軟測試冰淇淋形組合是特例。而招行測試橄欖球形更加代表了規模化測試推進的樣例。
測試金字塔理論上以L0爲基礎，數量最多。但從性價比上不是最經濟的，在規模化角度上，跨團隊接口聯通更加優先。
因此自動化測試裏面優先推進建設以接口/API測試爲特徵的L2自動化測試，然後L0，L1。而基於界面的L3測試更加排在後面。
【組織級工程實踐氛圍建設】
個別一線團隊會自動自發地建設持續集成，但如果在千人規模上考慮這個問題，就不能夠指望自動自發。因爲這裏面存在至少2重困難：
1，持續集成建設本身存在難度；
2，對如何實踐是否帶來高效率沒有統一認識。
因此要培養工程實踐氛圍，值得利用持續集成工具特性來開展組織級工程實踐度量，建立標杆，引領更多團隊前進。
對於指標樣例，有如下列推薦
- 測試用例數量，比如月度新增數量，起始時，不在於絕對數量，關鍵在於持續增加，如果總運行時間過長，那麼分多級運行，比如區分白天晚上
- 執行頻率，比如月度執行次數，執行頻率越高越好
- CI成功率，比如自然月成功率，100%成功意味着沒有充分利用CI，甚至爲了100%反而耗費了額外的工作量，推薦各組織摸索一個恰當到成功率區間
- 測試覆蓋率，比如月度比例趨勢，這又是一個微妙的指標，不能夠下降，但並不是越高越好，需要各組織摸索一個合適的區間
【小結】
持續集成是工程實踐規模化的核心實踐。其中的自動化測試推薦優先以基於接口/API的L2自動化測試。技術教練團隊值得考慮，但有難度，更重要的是提升工程實踐氛圍，值得收集並公開各種度量。