簡化 Web 應用程式的發布流程：具有功能標誌的基於主幹的開發-js教程-PHP中文網

首頁

web前端

js教程

簡化 Web 應用程式的發布流程：具有功能標誌的基於主幹的開發

Dec 23, 2024 pm 09:26 PM

在本文中，我們將概述一個健壯且高效的 Web 應用程式發布流程，該流程圍繞基於主幹的開發和基於環境的功能標誌構建。這種方法可確保持續整合、生產中的輕鬆測試以及從開發到發布的順利路徑，同時保持高品質標準。

核心原則

基於主幹的開發:
- 主幹分支充當所有開發工作的單一事實來源。
- 開發人員從新功能或 Jira 票證的主幹建立功能分支（例如，feature/xyz）。
- 拉取請求（PR）從這些功能分支提交到主幹，以便在測試成功後進行審查和合併。
環境為基礎的功能標誌:
- 功能標誌用於控制跨環境的功能活化。
- 標誌儲存在特定於環境的設定檔中或作為 CI/CD 管道配置的一部分。
- 在主幹分支中，所有功能標誌預設為 OFF。
- 可以根據需要在特定環境（例如沙盒、暫存或生產）中ON切換標誌。

Sprint 中的 JIRA 版本

Streamlined Release Process for a Web Application: Trunk-Based Development with Feature Flags

環境部署流程

沙箱或暫存環境：
- 對於 QA 和整合測試，團隊可以從主幹建立一個以 sandbox/ 為前綴的分支（例如 sandbox/xyz）。
- 此分支使用 CI/CD 管道部署到專用的沙箱或臨時環境。
- QA 團隊可以驗證新功能，整合測試可以確保相容性。
- 在此環境中將功能標誌切換為ON以測試特定功能。
生產發布準備：
- 要準備發布，請從主幹建立一個release/xyz 分支。
- release/xyz 分支作為候選版本，最初部署到 生產流量的 5% 用於 Beta 測試。
- 新功能的功能標誌在此分支中切換ON，以允許在生產中進行測試。
- Nginx 或類似的負載平衡器可以處理這種流量分割，確保只有一部分使用者看到變更。

功能標誌：範例與用法

標誌結構:
- 將功能標誌儲存在設定檔中（例如 config/feature-flags.json）：
```
 {
   "feature_xyz": false,
   "feature_abc": true
 }
```
登入後複製

在運行時使用環境變數來控制標誌：
```
 FEATURE_XYZ=true FEATURE_ABC=false npm start
```
登入後複製

後端範例:

在程式碼中切換標誌：

 const featureFlags = require('./config/feature-flags');

 if (featureFlags.feature_xyz) {
     console.log('Feature XYZ is enabled!');
 } else {
     console.log('Feature XYZ is disabled.');
 }

登入後複製

前端範例:

使用標誌有條件地渲染 UI 元件：

 if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
     render(&lt;NewFeatureComponent /&gt;);
 } else {
     render(&lt;OldFeatureComponent /&gt;);
 }

登入後複製

測試期間切換標誌:
- 要切換測試標誌，請更新配置或環境變數並重新啟動相關服務（前端或後端）：
```
 FEATURE_XYZ=true npm start
```
登入後複製

對於 CI/CD 管道，請確保在部署期間將適當的標誌值注入到環境中。

生產中測試

Beta 測試的流量路由:

使用Nginx配置來控制流量分配：

 http {
     upstream stable_backend {
         server stable_backend_1;
         server stable_backend_2;
     }

     upstream canary_backend {
         server canary_backend_1;
         server canary_backend_2;
     }

     upstream mixed_backend {
         server stable_backend_1 weight=45;
         server stable_backend_2 weight=45;
         server canary_backend_1 weight=5;
         server canary_backend_2 weight=5;
     }

     server {
         listen 80;
         server_name my-app.example.com;

         location / {
             if ($http_x_qa_test = "true") {
                 proxy_pass http://canary_backend;
                 break;
             }

             proxy_pass http://mixed_backend;
         }
     }
 }

登入後複製

透過調整負載平衡器權重，將 5% 的生產流量路由到執行新版本的伺服器。

生產中的專門 QA 測試：
- QA 團隊可以將自訂 Cookie（例如 qa-test=true）附加到他們的請求中。
- Nginx 100% 檢查此 cookie 並將這些請求路由到新版本，確保在生產中進行有針對性的測試。

穩定發表

修正問題：
- 開發人員透過向主幹分支開放 PR 來修復 Beta 測試期間發現的任何問題。
- 合併後，這些修復程序將被精心挑選到release/xyz分支。
完成發布：
- 所有問題解決且分支穩定後，發布分支會被標記為語意版本（例如v1.2.0），觸發部署到穩定後端。
- 產生版本說明以用於文件並與利害關係人共用。

修補程式

建立修補程式分支:
- 對於緊急修復，請直接從最新的生產標籤建立一個 hotfix/xyz 分支。
- 修補程式分支遵循與發布分支相同的穩定和標記過程。
版本控制：
- 修補程式依照語意版本控制 (SemVer) 標準增加修補程式版本（例如，從 v1.2.0 到 v1.2.1）。