在本文中，我們將概述一個健壯且高效的 Web 應用程序發(fā)布流程，該流程圍繞基于主干的開發(fā)和基于環(huán)境的功能標志構建。這種方法可確保持續(xù)集成、生產中的輕松測試以及從開發(fā)到發(fā)布的順利路徑，同時保持高質量標準。

---

核心原則

1. 基于主干的開發(fā):

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

2. 基于環(huán)境的功能標志:

   • 功能標志用于控制跨環(huán)境的功能激活。
   • 標志存儲在特定于環(huán)境的配置文件中或作為 CI/CD 管道配置的一部分。
   • 在主干分支中，所有功能標志默認設置為 OFF。
   • 可以根據需要在特定環(huán)境（例如沙盒、暫存或生產）中ON切換標志。

---

Sprint 中的 JIRA 版本

---

環(huán)境部署流程

1. 沙盒或暫存環(huán)境:

   • 對于 QA 和集成測試，團隊可以從主干創(chuàng)建一個以 sandbox/ 為前綴的分支（例如 sandbox/xyz）。
   • 此分支使用 CI/CD 管道部署到專用的沙箱或臨時環(huán)境。
   • QA 團隊可以驗證新功能，集成測試可以確保兼容性。
   • 在此環(huán)境中將功能標志切換為ON以測試特定功能。

2. 生產發(fā)布準備：

   • 要準備發(fā)布，請從主干創(chuàng)建一個release/xyz 分支。
   • release/xyz 分支作為候選版本，最初部署到 生產流量的 5% 用于 Beta 測試。
   • 新功能的功能標志在此分支中切換ON，以允許在生產中進行測試。
   • Nginx 或類似的負載均衡器可以處理這種流量分割，確保只有一部分用戶看到更改。

---

功能標志：示例和用法

1. 標志結構:

   • 將功能標志存儲在配置文件中（例如 config/feature-flags.json）：

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

• 在運行時使用環(huán)境變量來控制標志：
  

   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 />);
    } else {
        render(<OldFeatureComponent />);
    }
   

3. 測試期間切換標志:

   • 要切換測試標志，請更新配置或環(huán)境變量并重新啟動相關服務（前端或后端）：

    FEATURE_XYZ=true npm start
   

• 對于 CI/CD 管道，請確保在部署期間將適當的標志值注入到環(huán)境中。

---

生產中測試

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 并將這些請求路由到新版本，確保在生產中進行有針對性的測試。

---

穩(wěn)定發(fā)布

1. 修復問題：

   • 開發(fā)人員通過向主干分支開放 PR 來修復 Beta 測試期間發(fā)現的任何問題。
   • 合并后，這些修復程序將被精心挑選到release/xyz分支中。

2. 完成發(fā)布：

   • 所有問題解決并且分支穩(wěn)定后，發(fā)布分支會被標記為語義版本（例如v1.2.0），觸發(fā)部署到穩(wěn)定后端。
   • 生成版本說明以用于文檔并與利益相關者共享。

---

修補程序

1. 創(chuàng)建修補程序分支:

   • 對于緊急修復，請直接從最新的生產標簽創(chuàng)建一個 hotfix/xyz 分支。
   • 修補程序分支遵循與發(fā)布分支相同的穩(wěn)定和標記過程。

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 使用與角色或令牌綁定的特定測試帳戶登錄，以確保請求路由到新版本。

---

結論

此發(fā)布流程利用基于主干的開發(fā)和基于環(huán)境的功能標志來創(chuàng)建可擴展、可測試且生產安全的部署工作流程。通過使用沙箱環(huán)境、流量路由和專用測試策略，團隊可以提供高質量的功能，同時最大限度地降低風險。該方法可確保及早發(fā)現問題并有效解決，為無縫功能推出和修補程序鋪平道路。

以上是簡化 Web 應用程序的發(fā)布流程：具有功能標志的基于主干的開發(fā)的詳細內容。更多信息請關注PHP中文網其他相關文章！