小程序雲開發持續交付和質量管控（上）

保證交付效率和質量把控是一項業務長遠、穩定發展的必經之路，來自微信支付的張洪暉在第二屆小程序雲開發技術峯會上就介紹了高速發展的業務團隊如何利用小程序雲開發搞定持續交付和質量管控。

雲開發的老朋友

首先來看一下小程序的發展規模。根據微信發佈的 2019 年度報告，小程序在當年帶動了 536 萬就業，對社會的貢獻很是大，更可觀的是它的同比增加達到了 195%，能夠看到小程序生態發展地很是迅猛。

我所在的團隊是微信支付境外團隊，團隊出品的境外遊禮包項目的重要載體之一就是小程序，它能夠支持用戶到全世界各地均可以獲取咱們的匯率優惠和優惠券以及禮包優惠。

做爲第一批使用雲開發的團隊，稱得上是雲開發的「老朋友」。總的來講，從傳統的小程序開發模式，切換到雲開發模式以後，咱們的產出率增加了將近三倍。

你們可能會有疑問，爲何在切換到雲開發模式後，產出率會增加這麼多？要回答這個問題，先來看一下傳統的開發模式是怎樣的。

開發模式對比

傳統的開發模式中，前端須要負責小程序的 UI 以及邏輯構建，由後端來實現 CGI 和後端服務，而產品經理提需求，須要給前端同窗提一遍需求，同時也要給後端同窗同步需求，這裏就增長了溝通成本。

需求定下來以後，前端和後端的同窗是須要進行溝通協做的，這裏也存在必定的溝通成本，另外因爲後臺服務很是注重穩定性，須要作好風險把控，因此灰度流程會比較長。

上述的種種狀況對團隊的開發效率存在必定影響，而在切到雲開發模式以後，咱們的開發流程被大大簡化了：

後端同窗只須要關注後臺的服務，而 CGI 這一層徹底由雲函數去進行承擔，大部分場景下，產品需求只須要一個前端同窗就能夠完成了。另外，因爲前端同窗作全棧的開發，也省去了協商溝通的成本。

這對後端同窗也是很是有益的，目前在這種模式下，後端同窗能夠更關注於服務的穩定性以及提供一些能力，讓運營的玩法需求所有交給前端同窗去作。

團隊應用雲開發的痛點

通過一年的高速發展，項目用戶不斷增多，團隊不斷壯大，項目中使用的雲函數的數量也不斷在增長，讓咱們看到了一些隱患。

第一，項目發佈沒有審批。例如，在開發者工具上右鍵點擊上傳，查不到具體是由誰發佈，這時也沒有額外的審批環節，可能會致使發佈錯了以後難以溯源。

第二，雲函數是相互獨立的。爲了一些邏輯的互用，會提供一些公共的代碼，這些公共的代碼是經過腳本下發的方式來下發各個雲函數，這種方式有效提升了代碼複用率，可是反過來，若是發佈前忘記下發步驟，可能會致使代碼殘缺。

第三，咱們的雲函數的上傳方式是在開發者工具裏點擊右鍵完成上傳。因爲項目雲函數數量很是多，一個個點擊和發佈很是耗費時間，在十分順利的狀況下每每都須要兩個多小時進行部署和確認。

總結來看，項目小程序的部署發佈效率比較低，該如何去提高呢？此外，當流程較多時，須要注意的要點也很是多，該如何保證不出錯呢？

持續交付

這裏團隊就引入了持續交付的概念，得以讓咱們又好又快地使用雲開發。

上圖是持續交付流水線的總覽。觸發構建以後，經過手動觸發的方式，進入二級的審批流程，接着咱們會去倉庫裏面拉主代碼，拉完代碼以後，還會有一系列的代碼檢測和測試。

測試經過以後，纔會去走小程序和雲函數兩條發佈的流水線，發完以後會將版本發佈的消息同步給你們。

看到這裏，你們可能會有一個疑問：爲何要用手動觸發這種方式呢？它的效率是否是很低？

確實，除了手動觸發這種方式，其實還有 git hooks 這種自動觸發的方式，它的效率相對來講會比較高。

關於這個問題，團隊也進行了多維度的衡量與思考，結論是：自動觸發方式更適合的場景是測試環境，由於它對穩定性的要求並無那麼高，可是它須要即時去同步一些新的特性，最終，咱們在測試環境以及產品體驗的環節使用了自動觸發的方式，但真正對外進行發佈的時候，咱們會用手動觸發的方式保證質量，而且會有二級審批的流程。

高效部署

說到觸發，上文講到一個一個點擊雲函數的部署方式效率很是低，那麼咱們如何去作到高效地部署雲函數呢？

首先，團隊使用了雲開發提供的 CloudBase-manager-node 等基礎庫，並基於此封裝了獲取雲函數列表、部署單對雲函數以及全量部署雲函數等能力。

同時在小程序一側，利用 miniprogram-ci 這一自動化部署能力，封裝了自動上傳代碼包，優化了用開發者工具上傳的步驟，但在發佈以前，會提早去下發公共代碼，以保證代碼的完整性。

自動部署這種方式的效率很是高，用起來也很是爽，但若是發佈引入了一些 bug，可能會出現不少嚴重的後果，所以在持續交付過程當中咱們還引入了灰度發佈的能力。

灰度發佈

在初始化的時候，咱們的小程序和雲函數，會有小程序的新版本，雲函數有兩個環境：灰度環境和正式環境，現網的用戶拿到了現網的小程序版本，咱們能夠放心的把一些新的雲函數特性部署到灰度環境，把路徑指到灰度環境。

當開始灰度時，咱們會慢慢擴大灰度比例，把流量慢慢導入到灰度環境，同時現網的用戶拿到舊版本的比例有必定程度的降低，團隊也要看一下監控以及指標是否有問題，有問題的要快速進行回退。

當灰度完成的時候，現網全部的用戶拿到的都是正式版本的小程序，這個版本是 100%流量訪問灰度環境。剛纔所謂的灰度環境，這時候就變成了正式環境，而正式環境就變成了灰度環境，也即完成了藍綠髮布的一個切換，當進行下一次進行發佈的時候，就能夠把新的特性部署到咱們的灰度環境。

這種設計有很是大的優點，你們能夠思考一下。第一，它控制了變動的風險，能夠及時快速的進行回退；第二，客戶端和雲函數是一塊兒進行灰度的，即便須要作一些破壞性變動，例如協議變動時，也徹底不用擔憂線上的小程序版本是否兼容新的協議；第三是基於灰度設計的能力，適合作一些產品特性的快速驗證。

有了總體灰度的能力以後，你們可能會問，是否有對雲函數單獨灰度的能力？固然，咱們也設計了雲函數單獨灰度的能力。

能夠看到，咱們的小程序帶着版本號過來訪問，會請求到 getCloudEnv 這樣的雲函數，其實這個雲函數沒有作一些複雜的邏輯，只是單純的去雲 DB 裏面去獲取當前這個版本應該訪問到哪一個環境，這裏就會對灰度的比例以及白名單用戶進行一個判斷。

當咱們帶着版本號返回到前端的時候，前端小程序就會根據這個版本號去訪問到對應的灰度環境，團隊也是基於此設計了雲函數的單獨灰度。

這裏給你們看一下效果：下圖中，縱軸是灰度比例，橫軸是時間線，能夠看到紅色這條曲線是灰度比例，從 0 慢慢地放大到了 100%；而綠色這條曲線，當藍綠髮生切換的時候，流量從 100%慢慢降低到了 0。

除了用灰度發佈來控制變動風險，還有不少質量檢測的一些能力。好比說 Lint 檢查，防止代碼風格發生一些問題；自動化測試，來防止代碼變動影響現網的功能；還有一些代碼報告等。

最後，看一下持續交付的總體效果，在引入這條流水線和持續交互以後，代碼順利變動了 150 餘次，有效支撐了產品的迭代。

另外，部署時間也從原來的兩個小時縮短到了 5 分鐘，這大大節省了研發的人力。此外，在引入流水線以後，實現代碼變動 0 故障，讓發佈也更加安全。

以上是實踐案例的上半部分，下半部分將着重介紹團隊如何作好質量管控，敬請關注。

產品介紹

雲開發（Tencent CloudBase，TCB）是騰訊雲提供的雲原生一體化開發環境和工具平臺，爲開發者提供高可用、自動彈性擴縮的後端雲服務，包含計算、存儲、託管等serverless化能力，可用於雲端一體化開發多種端應用（小程序，公衆號，Web 應用，Flutter 客戶端等），幫助開發者統一構建和管理後端服務和雲資源，避免了應用開發過程當中繁瑣的服務器搭建及運維，開發者能夠專一於業務邏輯的實現，開發門檻更低，效率更高。