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

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

---

核心原則

1. 基於主幹的開發:

   • 主幹分支充當所有開發工作的單一事實來源。
   • 開發人員從新功能或 Jira 票證的主幹建立功能分支（例如，feature/xyz）。
   • 拉取請求（PR）從這些功能分支提交到主幹，以便在測試成功後進行審查和合併。

2. 環境為基礎的功能標誌:

   • 功能標誌用於控制跨環境的功能活化。
   • 標誌儲存在特定於環境的設定檔中或作為 CI/CD 管道配置的一部分。
   • 在主幹分支中，所有功能標誌預設為 OFF。
   • 可以根據需要在特定環境（例如沙盒、暫存或生產）中ON切換標誌。

---

Sprint 中的 JIRA 版本

---

環境部署流程

1. 沙箱或暫存環境：

   • 對於 QA 和整合測試，團隊可以從主幹建立一個以 sandbox/ 為前綴的分支（例如 sandbox/xyz）。
   • 此分支使用 CI/CD 管道部署到專用的沙箱或臨時環境。
   • QA 團隊可以驗證新功能，整合測試可以確保相容性。
   • 在此環境中將功能標誌切換為ON以測試特定功能。

2. 生產發布準備：

   • 要準備發布，請從主幹建立一個release/xyz 分支。
   • release/xyz 分支作為候選版本，最初部署到 生產流量的 5% 用於 Beta 測試。
   • 新功能的功能標誌在此分支中切換ON，以允許在生產中進行測試。
   • Nginx 或類似的負載平衡器可以處理這種流量分割，確保只有一部分使用者看到變更。

---

功能標誌：範例與用法

1. 標誌結構:

   • 將功能標誌儲存在設定檔中（例如 config/feature-flags.json）：

    {
      "feature_xyz": false,
      "feature_abc": true
    }
   

• 在運行時使用環境變數來控制標誌：
  

   FEATURE_XYZ=true FEATURE_ABC=false npm start
  

1. 後端範例:

   • 在程式碼中切換標誌：

    const featureFlags = require('./config/feature-flags');
   
    if (featureFlags.feature_xyz) {
        console.log('Feature XYZ is enabled!');
    } else {
        console.log('Feature XYZ is disabled.');
    }
   

2. 前端範例:

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

    if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
        render(<newfeaturecomponent></newfeaturecomponent>);
    } else {
        render(<oldfeaturecomponent></oldfeaturecomponent>);
    }
   

3. 測試期間切換標誌:

   • 要切換測試標誌，請更新配置或環境變數並重新啟動相關服務（前端或後端）：

    FEATURE_XYZ=true npm start
   

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

---

生產中測試

1. 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% 的生產流量路由到執行新版本的伺服器。

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

---

穩定發表

1. 修正問題：

   • 開發人員透過向主幹分支開放 PR 來修復 Beta 測試期間發現的任何問題。
   • 合併後，這些修復程序將被精心挑選到release/xyz分支。

2. 完成發布：

   • 所有問題解決且分支穩定後，發布分支會被標記為語意版本（例如v1.2.0），觸發部署到穩定後端。
   • 產生版本說明以用於文件並與利害關係人共用。

---

修補程式

1. 建立修補程式分支:

   • 對於緊急修復，請直接從最新的生產標籤建立一個 hotfix/xyz 分支。
   • 修補程式分支遵循與發布分支相同的穩定和標記過程。

2. 版本控制：

   • 修補程式依照語意版本控制 (SemVer) 標準增加修補程式版本（例如，從 v1.2.0 到 v1.2.1）。

---

分行清理

• 定期刪除合併的分支以避免混亂。
• 定期刪除未使用的功能標誌以維持組織。
• 使用 GitHub Actions 或類似工具在合併後自動刪除分支。

---

替代品質保證與測試策略

除了 cookie，在生產中路由 QA 流量的其他策略包括：

1. 基於標頭的路由:

   • QA 會為他們的請求添加自訂標頭（例如 X-QA-Test: true）。
   • Nginx 將這些請求路由到新版本進行測試。

2. 基於 IP 的路由:

   • 根據 QA 的 IP 位址限制新版本的流量。

3. 基於驗證令牌的路由:

   • QA 使用與角色或令牌綁定的特定測試帳戶登錄，以確保請求路由到新版本。

---

結論

此發布流程利用基於主幹的開發和基於環境的功能標誌來建立可擴展、可測試且生產安全的部署工作流程。透過使用沙箱環境、流量路由和專用測試策略，團隊可以提供高品質的功能，同時最大限度地降低風險。此方法可確保及早發現問題並有效解決，為無縫功能推出和修補程式鋪路。

以上是簡化 Web 應用程式的發布流程：具有功能標誌的基於主幹的開發的詳細內容。更多資訊請關注PHP中文網其他相關文章！