简化 Web 应用程序的发布流程：具有功能标志的基于主干的开发-js教程-PHP中文网

在本文中，我们将概述一个健壮且高效的 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(<NewFeatureComponent />);
 } else {
     render(<OldFeatureComponent />);
 }

登录后复制

测试期间切换标志:
- 要切换测试标志，请更新配置或环境变量并重新启动相关服务（前端或后端）：
```
 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）。