本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

DevOps在開發生命周期中起著不可或缺。大多數前端框架都配有如Webpack一般的模塊捆綁器，以負責繁重的工作。但是，我們仍然需要規劃如何連接捆綁持續集成(CI)和持續交付(CD)環境的前端工具。

本文關注5種能在單頁應用程序中使用DevOps的策略。

[[348753]]

1. 減少環境配置

當使用React、Angular和Vue創建單個頁面應用的結構時，常規操作是每個環境使用單獨的配置文件。通常，開發、生產等使用一個環境配置。若每個環境彼此不同，便有多個配置文件。

但是，在本應使用不同捆綁配置情況下，若開發和生產只使用兩個配置，而其他應用程序特定的變量，如API路徑和主機名等在生成后修改，又會怎么樣呢?通過保留這兩個配置，你可以分開本地開發配置與其余配置(生產、暫存和質量保證)。

如果將Build和Release劃分為兩個管道，可以先放完整的占位符，然后反復使用Build管道來創建構件。之后，根據部署環境，可以在Release管道中動態替換這些變量。這種方法主要有兩個優點： 

• 可將相同捆綁器推入多個環境(使用基礎的字符串替換)，節省寶貴構建時間。
• 掌握對捆綁器所做的確切更改，特別是在特定環境中。

2. 設置質量門

在Pull Request合并到開發分支之前，先構建前端的做法很常見。

質量門的概念連接著Pull Request構建，你可以在其中設置其他步驟(或門)以確保質量。例如，可以用一個構建步驟來用linter執行操作，以確保修改或添加的任何代碼與已經遵循的代碼樣式沒有任何偏差。做完這步后，可以用SonarCloud等高級代碼質量工具來進行質量檢查，通過詳細的見解向Pull Request本身提供反饋。

你或許會問，為什么在簽入代碼之前就不進行IDE級別的這些代碼質量評估?是的，在IDE級別進行這些評估(如果有可用的IDE插件)很重要，這能避免花時間在反饋周期上。但是，保證質量以進行整體代碼質量管理同樣重要。

[[348754]]

圖源：unsplash

3. 緩存程序包安裝

NPM軟件包安裝占很大一部分端構建的執行時間。重復構建時，由于很少更改外部依賴項，很難改善這個情況。

改進后，你可以設置一個緩存步驟來緩存這些依賴項。在特定的DevOps平臺(例如AzureDevOps)中，預定義的步驟可以執行此操作。但是，如果無法在DevOps平臺中找到它，可以基于package.json內容創建一個哈希函數，并將其用作緩存鍵來執行相同的操作。

4. 尋找并行性

在某些情況下，當在DevOps管道上構建Web應用程序時，需要同時構建前端和后端。由于大多數DevOps平臺都使用代理支持并行性，因此，可以將前端構建和后端劃分為不同的代理。借此，完成構建所需的時間便減少了。

如果將DevOps步驟劃為Build和Release管道，甚至可以在Release管道上組合前端和后端構建構件(前提是兩者都部署到同一服務器上)。

此外，即使在構建管道中，還可以用其他步驟來執行并行操作。重要的是，嘗試使用并行性進行各種優化，并評估其對整體DevOps的影響，以根據經驗教訓進行改進。

5. 自動化測試的有效執行

最后，我想采取一個關鍵步驟，需要在DevOps管道中進行設置。盡管最好是在Pull Request級別執行這些步驟(在開發人員的設備上更佳)，但需要根據測試執行時間來確定正確的執行位置。

例如，作為質量門的一部分，在Pull Request構建時執行單元測試是一種常見的做法。但是，如果執行要花幾分鐘時間(常事)，則在此級別上運行E2E測試可能會成為一筆開銷。因此，評估情況并決定在不同級別運行E2E測試用例至關重要。

圖源：unsplash

如你所見，我們可以對DevOps進行不同的改進，以提高效率并提升應用程序的整體質量。此外，其中的一些技術同樣適用于后端。

雖然本文只討論了五種策略，但是這些策略的方向可能會有助于進一步改進管道，以提高其性能(如根據構建步驟在各個級別進行緩存的技術)。

但還需要注意的是，每項改進都需要付出一定的代價。如果使用相同的緩存示例則應該知道，即使你指定NPM依賴項的自動更新小補丁，也有可能不使用庫的最新更新。最后，希望這些步驟將有助于你更好地使用DevOps并改善現有管道。