部署集成✅

CI 和 CD 的区别

答案

核心概念：

类型	全称	作用	关键活动
CI	Continuous Integration（持续集成）	自动化构建和测试代码变更	代码合并、自动构建、单元测试、代码质量检查
CD	Continuous Deployment/Delivery（持续部署/交付）	自动化发布和部署应用	自动部署、环境管理、版本发布、回滚策略

主要差异：

1. 阶段不同：CI 侧重代码集成和质量保证，CD 侧重交付和部署
2. 目标不同：CI 确保代码可构建和可测试，CD 确保应用可稳定部署
3. 触发机制：CI 通常由代码提交触发，CD 可手动或自动触发

面试官视角：

• 要点：能清晰区分两者的作用域和目标
• 加分项：结合实际项目经验说明 CI/CD 流程设计
• 常见失误：混淆两者概念，不理解具体实践

延伸阅读

• CI/CD 最佳实践
• Martin Fowler 论 CI

前端应用 CICD 有哪些方式实现

答案

前端应用的持续集成与持续部署（CI/CD）可以通过以下几种方式实现：

一、使用 Jenkins

1. 持续集成：

• Jenkins 可以监听代码仓库（如 Git）的变化，当有新的代码提交时，自动触发构建任务。
• 对于前端项目，可以配置 Jenkins 执行构建命令，如使用 npm 或 yarn 安装依赖、运行构建脚本等。
• 例如，可以创建一个自由风格的项目，配置源代码管理为你的 Git 仓库地址，并在构建步骤中添加“Execute shell”，输入构建命令，如npm install && npm run build。

2. 持续部署：

• 构建成功后，Jenkins 可以将构建生成的静态文件部署到目标服务器上。
• 可以使用插件（如 Publish Over SSH）将文件传输到远程服务器，并执行部署脚本。
• 例如，配置插件连接到目标服务器，设置部署目录，然后在构建后操作中选择“Send build artifacts over SSH”，指定要传输的文件和目标服务器信息。

二、使用 GitLab CI/CD

1. 持续集成：

• 在.gitlab-ci.yml文件中定义一系列的阶段（stages）和任务（jobs）。
• 当代码推送到 GitLab 仓库时，GitLab Runner 会自动执行这些任务。
• 对于前端项目，可以定义一个build job，在其中执行构建命令。
• 例如：

stages:
- build

build:
stage: build
script:
- npm install
- npm run build

2. 持续部署：

• 可以在.gitlab-ci.yml中定义deploy job，将构建生成的静态文件部署到服务器上。
• 可以使用 SSH 密钥或其他部署工具来实现部署。
• 例如：

stages:
- build
- deploy

build:
stage: build
script:
- npm install
- npm run build

deploy:
stage: deploy
script:
- scp -r dist/* user@server:/path/to/deploy

三、使用 GitHub Actions

1. 持续集成：

• 在.github/workflows目录下创建一个 YAML 文件来定义工作流。
• 当代码推送到 GitHub 仓库时，GitHub Actions 会自动执行工作流中的任务。
• 对于前端项目，可以在工作流中执行构建命令。
• 例如：

name: CI/CD for Frontend App

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install dependencies
run: npm install
- name: Build
run: npm run build

2. 持续部署：

• 可以在工作流中添加部署步骤，使用 SSH、FTP 等方式将静态文件部署到服务器上。
• 或者使用云服务提供商的部署服务，如 AWS Amplify、Netlify 等。
• 例如：

name: CI/CD for Frontend App

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install dependencies
run: npm install
- name: Build
run: npm run build

deploy:
needs: build
runs-on: ubuntu-latest
steps:
- name: Deploy to Server
run: scp -r dist/* user@server:/path/to/deploy

四、使用 Travis CI

1. 持续集成：

• 在项目根目录下创建一个.travis.yml文件来定义构建配置。
• 当代码推送到支持的代码仓库（如 GitHub）时，Travis CI 会自动触发构建。
• 对于前端项目，可以在配置文件中指定构建命令。
• 例如：

language: node_js
node_js:
- 12

script:
- npm install
- npm run build

2. 持续部署：

• 可以在构建成功后，使用部署工具或脚本将静态文件部署到服务器上。
• 例如，可以在.travis.yml中添加部署步骤，使用 SSH 或其他方式进行部署。

 language: node_js
 node_js:

- 12

 script:

- npm install
- npm run build

 after_success:

- scp -r dist/* user@server:/path/to/deploy

延伸阅读

• Jenkins 官方文档
• GitLab CI/CD
• GitHub Actions
• 前端 CI/CD 最佳实践

应用如何做应用灰度发布

答案

这个是一个非常复杂的话题， 没法直接给出答案， 进提供一些实现的思路：

什么是灰度

灰度系统可以把流量划分成多份，一份走新版本代码，一份走老版本代码。

而且灰度系统支持设置流量的比例，比如可以把走新版本代码的流程设置为 5%，没啥问题再放到 10%，50%，最后放到 100% 全量。

这样可以把出现问题的影响降到最低。

而且灰度系统不止这一个用途，比如产品不确定某些改动是不是要的，就要做 AB 实验，也就是要把流量分成两份，一份走 A 版本代码，一份走 B 版本代码。

实现思路

1. 后端支持：灰度上线需要后端的支持，通过后端的灰度发布控制，可以将不同版本的前端应用分配给不同用户。

2. 搭建网关层： 支持一部分用户分发到 A 版本， 一部分用户分发到 B 版本 （通常使用 nginx 搭建）。

3. 版本管控机制： 使用版本控制系统（如Git、package.version、hash version 等）来管理不同版本的前端应用代码。在灰度上线时，可以根据需要切换到特定的版本。

4. 动态路由：通过动态路由配置，将用户请求导向不同版本的前端应用。例如，可以使用Nginx或其他反向代理服务器来实现动态路由。

5. 流量染色：使用Cookie或Session来控制用户的灰度版本访问。可以通过设置不同的Cookie值或Session标记，将用户分配到不同的灰度版本。

6. 更复杂的漏量配置： 例如要根据部门、权限、角色等方式来开放灰度；可以使用让用户访问应用的时候， 查询其权限和角色， 根据权限和角色来分发不同的页面路由。

参考文档

• 基于 Nginx 实现一个灰度上线系统

应用的灰度发布是将新版本逐步推出给有限的用户群体，以在完全发布之前监控其性能和搜集用户反馈的过程。这可以确保新版本的稳健性，减少因新版本可能引起的问题对所有用户的影响。以下是实现应用灰度发布的几种常见方法：

1. 基于 HTTP 头或 Cookie 的路由

通过识别用户的 HTTP 请求头（如 User-Agent）或特定的 Cookie，决定用户请求被路由到新版本还是旧版本的应用。这种方法通常需要负载均衡器或网关支持特定路由规则。

2. 使用服务网格（Service Mesh）

服务网格如 Istio 提供了复杂的流量管理能力，可以在微服务架构中实现灰度发布。通过定义路由规则，Istio 可以将特定比例或特定条件的流量导向新版本服务。

3. 功能开关（Feature Toggles）

功能开关允许开发者在代码中嵌入开关，根据配置动态激活或关闭某些功能。这样，新版本的功能可以被隐藏，直到你决定通过更改配置为特定用户群体开放。

4. DNS 路由

通过 DNS 管理，将部分用户的请求解析到部署了新版本应用的服务器上。这种方法简单，但切换和回退可能不如其他方法灵活。

5. CDN 切换

对于前端应用或静态资源，可以通过 CDN 配置，将部分用户的请求路由到包含新版本资源的 CDN 上。通过调整 CDN 的缓存规则控制版本切换。

6. A/B 测试平台

将灰度发布作为 A/B 测试的一部分，使用专门的 A/B 测试平台来控制哪些用户看到新版本。这种方法不仅可以实现灰度发布，还能搜集用户反馈和使用情况数据。

7. 容器编排和管理

在支持容器编排（如 Kubernetes）的环境中，可以通过部署新版本的 Pod 副本，并逐步增加新版本副本的数量，同时减少旧版本副本的数量实现灰度发布。

在实施灰度发布时，应该配合监控和日志记录工具，以便快速识别并解决新版本可能引入的问题。同时，在决定完全推出新版本之前，逐渐增加访问新版本的用户比例，确保在所有阶段都能够保持应用的稳定性和高性能。

延伸阅读

• 灰度发布最佳实践
• 基于 Nginx 实现灰度发布
• Kubernetes 灰度发布