简化 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中文网其他相关文章！