🛠️ 工程化工具 - CICD

What is CI/CD? What problems does it solve?

• 考察点：CI/CD基础概念。

答案：

CI/CD是持续集成（Continuous Integration）和持续部署（Continuous Deployment/Delivery）的缩写，是现代软件开发中的重要实践方法。CI/CD通过自动化的方式将代码从开发、测试到部署的整个流程串联起来，实现快速、可靠的软件交付。

主要组成部分：

1. 持续集成（CI）： 开发者频繁地将代码变更合并到主分支，每次提交都会触发自动化构建和测试
2. 持续部署（CD）： 在CI的基础上，自动将通过测试的代码部署到生产环境
3. 持续交付（CD）： 确保代码随时处于可部署状态，但部署到生产环境需要手动触发

解决的核心问题：

• 集成风险： 避免大规模代码合并时的冲突和错误
• 手动错误： 减少人工操作导致的部署失误和环境不一致
• 反馈延迟： 快速发现代码问题，缩短从开发到用户反馈的周期
• 发布效率： 提高软件发布频率和质量，支持敏捷开发

适用场景：

• 团队协作开发项目
• 需要频繁发版的产品
• 对代码质量要求较高的系统
• 微服务架构和现代化应用部署

What’s the difference between continuous integration and continuous deployment?

• 考察点：CI与CD的区分。

答案：

持续集成（CI）和持续部署（CD）是CI/CD流程中的两个不同阶段，各自承担不同的职责和目标。

持续集成（Continuous Integration - CI）：

• 目标： 确保代码变更能够安全地集成到主分支
• 触发时机： 开发者提交代码到版本控制系统时
• 主要流程： 代码检出 → 依赖安装 → 编译构建 → 自动化测试 → 代码质量检查
• 产出结果： 可部署的制品（如打包文件、镜像等）
• 关注点： 代码质量、构建成功率、测试覆盖率

持续部署（Continuous Deployment - CD）：

• 目标： 将已验证的代码自动部署到目标环境
• 触发时机： CI流程成功完成后
• 主要流程： 环境准备 → 制品部署 → 服务启动 → 健康检查 → 流量切换
• 产出结果： 运行中的应用服务
• 关注点： 部署成功率、服务可用性、回滚能力

核心差异对比：

• 范围： CI侧重代码集成和质量验证，CD侧重部署和服务交付
• 风险： CI主要防范代码集成风险，CD主要防范部署和运行风险
• 反馈： CI提供构建和测试结果，CD提供服务运行状态
• 自动化程度： CI通常完全自动化，CD可以选择手动审批或完全自动

What are the common CI/CD tools?

• 考察点：工具了解程度。

答案：

CI/CD工具生态系统丰富多样，可以根据团队需求、技术栈和预算选择合适的工具组合。

云原生CI/CD平台：

• GitHub Actions： 与GitHub深度集成，支持丰富的Action市场
• GitLab CI/CD： 内置CI/CD功能，提供完整的DevOps解决方案
• Azure DevOps： 微软云平台的CI/CD服务
• AWS CodePipeline： 亚马逊云的持续集成和部署服务
• Google Cloud Build： 谷歌云的构建和部署平台

传统CI/CD工具：

• Jenkins： 开源自动化服务器，插件生态丰富
• TeamCity： JetBrains开发的CI/CD服务器
• Bamboo： Atlassian的CI/CD解决方案
• CircleCI： 云端CI/CD平台，配置简单
• Travis CI： 专注于开源项目的CI服务

容器化部署工具：

• Docker： 容器化应用打包和运行
• Kubernetes： 容器编排和自动化部署
• Helm： Kubernetes应用包管理
• ArgoCD： Kubernetes原生的GitOps工具

前端专用工具：

• Vercel： 专为前端应用设计的部署平台
• Netlify： 静态网站和JAMstack应用部署
• Surge.sh： 简单的静态网站部署工具

选择工具时需考虑：团队技术栈、项目规模、成本预算、集成需求等因素。

What is the role of Git hooks in CI/CD?

• 考察点：版本控制集成。

答案：

Git hooks是Git版本控制系统提供的钩子机制，允许在特定Git事件发生时自动执行脚本。在CI/CD流程中，Git hooks起到触发器和质量把关的重要作用。

主要类型和作用：

客户端hooks（本地执行）：

• pre-commit： 提交前执行，用于代码质量检查

  # 示例：运行eslint检查
  #!/bin/sh
  npm run lint
  

• commit-msg： 提交信息验证，确保符合规范
• pre-push： 推送前执行，可运行单元测试

服务端hooks（远程仓库执行）：

• pre-receive： 接收推送前执行，可进行权限验证
• post-receive： 接收推送后执行，触发CI/CD流程
• update： 分支更新时执行，可实现分支保护

在CI/CD中的应用场景：

• 自动触发构建： post-receive hook触发Jenkins或其他CI工具
• 代码质量门禁： pre-commit执行lint、格式化检查
• 分支保护策略： 防止直接推送到保护分支
• 自动化测试： 推送时触发单元测试和集成测试
• 部署触发： 特定分支推送时自动触发部署流程

最佳实践：

• 使用husky等工具管理客户端hooks
• hooks脚本要快速执行，避免影响开发体验
• 提供绕过机制处理紧急情况
• 与CI/CD平台的webhook机制结合使用

Git hooks为CI/CD提供了版本控制层面的自动化入口，是实现DevOps流程的重要组成部分。

What steps are included in the build process of front-end projects?

• 考察点：构建流程理解。

答案：

前端项目的构建流程是将源代码转换为可在生产环境运行的静态资源的过程，涉及多个步骤的协调配合。

核心构建步骤：

1. 环境准备阶段：

• 依赖安装： npm install 或 yarn install 安装项目依赖
• 环境变量配置： 设置构建环境变量（dev/test/prod）
• 工具链检查： 验证Node.js版本、构建工具版本

2. 代码处理阶段：

• TypeScript编译： .ts 文件转换为 .js 文件
• JSX转换： React JSX语法转换为标准JavaScript
• ES6+转译： 使用Babel将现代JavaScript转换为兼容版本
• CSS预处理： Sass/Less/Stylus转换为标准CSS

3. 资源优化阶段：

• 代码压缩： JavaScript和CSS代码压缩（minify）
• 图片优化： 图片压缩、格式转换、响应式处理
• 资源合并： 多个文件合并减少HTTP请求
• Tree Shaking： 移除未使用的代码

4. 打包构建阶段：

• 模块打包： 使用Webpack/Vite等工具进行模块打包
• 代码分割： 按需加载、路由分割、第三方库分离
• Hash生成： 为静态资源生成唯一hash值实现缓存控制
• Source Map生成： 生成调试用的源码映射文件

5. 质量检查阶段：

• 单元测试： 运行Jest、Mocha等测试框架
• 端到端测试： 执行Cypress、Playwright等E2E测试
• 代码质量检查： ESLint、Prettier、SonarQube等工具检查

6. 输出部署阶段：

• 构建产物生成： 输出dist/build目录
• 部署包准备： 压缩、上传到CDN或静态服务器
• 版本管理： 构建信息记录、版本标记

现代前端构建工具如Vite、Turbo等大大简化了这一流程，提供了开箱即用的优化配置。

How to design CI/CD pipelines for front-end projects?

• 考察点：流水线设计能力。

答案：

前端项目的CI/CD流水线设计需要考虑前端应用的特殊性，如静态资源处理、多环境部署、CDN缓存等因素，构建高效可靠的自动化流程。

流水线架构设计：

阶段一：代码质量检查（CI Pipeline）

# 示例GitHub Actions配置
- name: Code Quality Check
  run: |
    npm install
    npm run lint          # ESLint检查
    npm run type-check    # TypeScript类型检查
    npm run test          # 单元测试
    npm run test:e2e      # E2E测试

阶段二：构建和打包

- name: Build Application
  run: |
    npm run build:prod    # 生产环境构建
    npm run analyze       # 构建分析

阶段三：部署准备

• 静态资源上传： 将构建产物上传到CDN
• 版本标记： 给构建产物打标签便于回滚
• 环境配置： 根据目标环境注入配置

阶段四：分环境部署（CD Pipeline）

• 测试环境： 自动部署，用于功能验证
• 预发布环境： 手动触发，模拟生产环境
• 生产环境： 审批后部署，支持灰度发布

关键设计原则：

• 分支策略： 不同分支触发不同流水线（feature/develop/main）
• 并行执行： 代码检查、测试、构建等步骤并行提高效率
• 失败快速反馈： 在流水线早期发现问题，减少资源浪费
• 制品管理： 构建产物版本化管理，支持快速回滚

监控和通知：

• 流水线执行状态实时通知（Slack/钉钉/邮件）
• 部署成功后的健康检查和监控告警
• 性能指标监控（构建时间、包大小等）

最佳实践：

• 使用构建缓存加速流水线执行
• 实现蓝绿部署或滚动部署减少服务中断
• 配置自动回滚机制应对部署失败

What are the applications of Docker in front-end deployment?

• 考察点：容器化部署理解。

答案：

Docker容器化技术在前端部署中提供了环境一致性、部署标准化和运维简化的优势，特别适合现代化的前端应用部署场景。

Docker在前端部署中的应用模式：

1. 静态资源容器化部署：

# 多阶段构建示例
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

2. SSR应用容器化：

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

主要应用场景：

开发环境标准化：

• 环境一致性： 确保开发、测试、生产环境完全一致
• 依赖管理： 容器内包含所有运行时依赖，避免环境差异
• 快速启动： 新团队成员可快速搭建开发环境

生产环境部署：

• 蓝绿部署： 使用容器编排实现无缝切换
• 水平扩容： 根据流量自动扩缩容器实例
• 版本管理： 容器镜像版本化，支持快速回滚

微前端架构支持：

• 服务隔离： 每个微前端应用独立容器化
• 独立部署： 各模块可独立构建、测试、部署
• 统一网关： 使用Nginx/Traefik等容器作为统一入口

优势特点：

• 环境隔离： 避免不同项目间的依赖冲突
• 资源控制： 精确控制CPU、内存等资源使用
• 安全性： 容器沙箱环境提供额外安全保障
• 可移植性： 在任何支持Docker的平台运行

最佳实践：

• 使用多阶段构建减小镜像大小
• 合理使用缓存层优化构建速度
• 配置健康检查确保服务可用性
• 使用Docker Compose简化本地开发

What are the management strategies for multi-environment deployment?

• 考察点：环境管理能力。

答案：

多环境部署管理是确保软件在不同阶段稳定运行的关键实践，需要制定清晰的环境策略、配置管理和部署流程。

环境分层策略：

1. 开发环境（Development）：

• 目的： 开发人员日常编码和功能开发
• 特点： 频繁变更、调试工具齐全、性能要求低
• 部署方式： 自动部署、实时热更新

2. 测试环境（Testing/QA）：

• 目的： 功能测试、集成测试、性能测试
• 特点： 接近生产配置、数据相对稳定
• 部署方式： 基于feature分支自动部署

3. 预发布环境（Staging/Pre-production）：

• 目的： 最终验证、用户验收测试
• 特点： 完全模拟生产环境、真实数据测试
• 部署方式： 手动触发、严格审批流程

4. 生产环境（Production）：

• 目的： 为最终用户提供服务
• 特点： 高可用、高性能、安全性最高
• 部署方式： 严格审批、灰度发布、监控完善

配置管理策略：

环境变量分离：

// 配置文件示例
const config = {
  development: {
    apiUrl: 'http://localhost:3001',
    dbUrl: 'mongodb://localhost:27017/dev'
  },
  testing: {
    apiUrl: 'https://api-test.example.com',
    dbUrl: 'mongodb://test-db:27017/test'
  },
  production: {
    apiUrl: 'https://api.example.com',
    dbUrl: process.env.DATABASE_URL
  }
};

基础设施即代码（IaC）：

• Terraform： 定义和管理云资源
• Ansible： 自动化配置管理
• Kubernetes Manifests： 容器化应用配置

部署策略管理：

环境晋升流程：

1. 开发环境 → 测试环境：功能开发完成后自动晋升
2. 测试环境 → 预发布环境：测试通过后手动晋升
3. 预发布环境 → 生产环境：验收通过后审批晋升

数据管理策略：

• 开发/测试环境： 使用脱敏的生产数据或模拟数据
• 预发布环境： 使用生产数据副本进行验证
• 生产环境： 真实用户数据，严格权限控制

监控和告警：

• 环境状态实时监控
• 部署成功率和失败率统计
• 环境间配置差异检测和告警

最佳实践：

• 环境配置版本化管理
• 自动化环境创建和销毁
• 建立环境使用规范和权限控制
• 定期环境一致性检查和修复

How to integrate automated testing in CI/CD?

• 考察点：测试自动化集成。

答案：

自动化测试是CI/CD流程中的核心组成部分，通过不同层级的测试策略确保代码质量和功能正确性，实现快速可靠的软件交付。

测试金字塔模型集成：

1. 单元测试（Unit Tests）：

• 执行时机： 每次代码提交时触发
• 集成位置： CI流程早期，构建前执行
• 工具选择： Jest、Mocha、Vitest等

# CI配置示例
- name: Unit Tests
  run: |
    npm test -- --coverage
    npm run test:unit --watchAll=false

2. 集成测试（Integration Tests）：

• 执行时机： 构建成功后执行
• 测试范围： API接口、组件间交互、数据库操作
• 工具选择： Supertest、Testing Library等

- name: Integration Tests
  run: |
    docker-compose up -d db
    npm run test:integration
    docker-compose down

3. 端到端测试（E2E Tests）：

• 执行时机： 部署到测试环境后执行
• 测试范围： 完整用户流程、跨浏览器兼容性
• 工具选择： Cypress、Playwright、Puppeteer等

- name: E2E Tests
  run: |
    npm run build
    npm start &
    npx wait-on http://localhost:3000
    npm run test:e2e

CI/CD集成策略：

并行测试执行：

• 不同测试类型并行运行提高效率
• 使用测试矩阵覆盖多个环境和配置
• 智能测试分组和负载均衡

测试门禁机制：

• 质量门禁： 测试覆盖率不达标阻止合并
• 性能门禁： 性能测试不通过阻止部署
• 安全门禁： 安全扫描发现问题阻止发布

测试数据管理：

// 测试环境数据准备
beforeEach(async () => {
  await seedDatabase();
  await clearCache();
});

afterEach(async () => {
  await cleanupTestData();
});

测试报告和反馈：

• 实时反馈： 测试失败立即通知相关开发者
• 测试报告： 生成详细的测试报告和覆盖率统计
• 趋势分析： 跟踪测试成功率和执行时间趋势

不同环境的测试策略：

• 开发环境： 快速单元测试反馈
• 测试环境： 完整回归测试套件
• 预发布环境： 关键业务流程验证
• 生产环境： 健康检查和烟雾测试

性能和优化：

• 测试缓存： 缓存依赖和测试数据减少执行时间
• 增量测试： 只运行相关变更的测试
• 并发执行： 利用多核CPU并行运行测试
• 云端测试： 使用云服务扩展测试资源

最佳实践：

• 建立清晰的测试分层和职责划分
• 保持测试的独立性和可重复性
• 定期维护和更新测试用例
• 监控测试执行时间和稳定性

What are the implementation and strategies for deployment rollback?

• 考察点：部署风险控制。

答案：

部署回滚是CI/CD流程中的重要安全机制，用于在部署出现问题时快速恢复到稳定版本，最大限度减少服务中断时间和用户影响。

回滚策略类型：

1. 蓝绿部署（Blue-Green Deployment）：

• 原理： 维护两套完全相同的生产环境
• 回滚方式： 流量切换回原环境
• 优势： 瞬间回滚，零停机时间

# 蓝绿部署示例
deploy_blue:
  script: |
    deploy_to_environment "blue"
    health_check "blue"
    
switch_traffic:
  script: |
    switch_traffic_to "blue"
    
rollback:
  script: |
    switch_traffic_to "green"  # 回滚到绿环境

2. 滚动部署（Rolling Deployment）：

• 原理： 逐步替换服务实例
• 回滚方式： 逐步恢复旧版本实例
• 优势： 资源利用率高，渐进式回滚

rolling_rollback:
  script: |
    for instance in $(get_instances); do
      stop_instance $instance
      deploy_previous_version $instance
      health_check $instance
      sleep 30
    done

3. 金丝雀部署（Canary Deployment）：

• 原理： 小流量验证新版本
• 回滚方式： 停止金丝雀流量，回到稳定版本
• 优势： 降低影响范围，风险可控

canary_rollback:
  script: |
    set_traffic_split stable:100 canary:0
    remove_canary_instances

前端特定回滚策略：

静态资源回滚：

// CDN版本切换
const rollbackToVersion = (version) => {
  updateCDNConfiguration({
    origin: `https://cdn.example.com/v${version}/`,
    cacheInvalidation: true
  });
};

配置驱动回滚：

// 功能开关回滚
const rollbackFeatures = () => {
  updateFeatureFlags({
    newFeature: false,
    betaUI: false
  });
};

回滚触发机制：

自动回滚条件：

• 健康检查失败： 连续健康检查失败超过阈值
• 错误率飙升： 5xx错误率超过预设值
• 性能下降： 响应时间超过基线的200%
• 业务指标异常： 核心业务指标下降

手动回滚机制：

# 命令行回滚工具
./deploy rollback --version=v1.2.3 --environment=production

回滚实现技术：

版本管理：

• 镜像标签： Docker镜像版本化管理
• 制品仓库： 保留历史版本制品
• 数据库版本： 数据库迁移版本控制

状态保持：

# Kubernetes回滚示例
rollback_deployment:
  script: |
    kubectl rollout undo deployment/app --to-revision=2
    kubectl rollout status deployment/app

监控和告警：

• 回滚触发告警： 回滚操作立即通知相关人员
• 回滚状态监控： 实时监控回滚进度和结果
• 影响评估： 分析回滚对用户的影响程度

数据一致性处理：

• 向前兼容： 确保新版本数据能被旧版本正常处理
• 数据快照： 部署前创建数据快照
• 补偿事务： 回滚时执行数据补偿逻辑

最佳实践：

• 建立明确的回滚决策流程和权限
• 定期进行回滚演练验证机制有效性
• 记录回滚原因和影响分析
• 优化回滚时间，争取在5分钟内完成

How to design CI/CD architecture for large front-end applications?

• 考察点：CI/CD架构思维。

答案：

大型前端应用的CI/CD架构设计需要考虑代码规模、团队协作、性能优化、可扩展性等多维度因素，构建适应复杂业务场景的自动化体系。

架构设计原则：

1. 分层架构设计：

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   代码仓库层     │    │   构建调度层     │    │   部署执行层     │
│  ┌───────────┐   │    │  ┌───────────┐   │    │  ┌───────────┐   │
│  │ Git Repos │   │───▶│  │ Jenkins   │   │───▶│  │Kubernetes │   │
│  │Monorepo/  │   │    │  │GitHub     │   │    │  │Docker     │   │
│  │Multi-repo │   │    │  │Actions    │   │    │  │Cloud      │   │
│  └───────────┘   │    │  └───────────┘   │    │  └───────────┘   │
└─────────────────┘    └─────────────────┘    └─────────────────┘

2. 微服务化CI/CD架构：

// 项目配置示例
const pipelineConfig = {
  projects: [
    {
      name: "main-app",
      type: "spa",
      dependencies: ["shared-components"],
      deployTarget: "cdn"
    },
    {
      name: "admin-dashboard", 
      type: "ssr",
      dependencies: ["shared-utils"],
      deployTarget: "kubernetes"
    }
  ],
  sharedLibraries: [
    "shared-components",
    "shared-utils",
    "design-system"
  ]
};

大规模代码管理策略：

Monorepo vs Multi-repo：

• Monorepo： 统一版本管理，依赖共享，构建优化

# Nx/Lerna构建配置
build_affected:
  script: |
    nx affected:build --base=main~1 --parallel=3
    nx affected:test --base=main~1 --parallel=3

• Multi-repo： 独立演进，团队自治，技术栈多样化

# 跨仓库依赖管理
dependency_update:
  script: |
    update_shared_library_version
    trigger_downstream_builds

性能优化架构：

构建缓存体系：

# 多阶段构建缓存优化
FROM node:18-alpine AS deps
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

FROM node:18-alpine AS builder  
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

分布式构建：

• 构建农场： 多台构建机器并行处理
• 云端构建： 利用云服务弹性扩容
• 增量构建： 只构建变更影响的模块

质量保障体系：

多层次质量门禁：

quality_gates:
  - stage: "code_analysis"
    tools: ["eslint", "sonarqube", "codecov"]
    thresholds:
      coverage: 80%
      duplications: 3%
      
  - stage: "security_scan" 
    tools: ["snyk", "audit", "license-check"]
    
  - stage: "performance_test"
    tools: ["lighthouse", "bundle-analyzer"]
    thresholds:
      performance_score: 90
      bundle_size: "2MB"

环境管理架构：

基础设施即代码：

# Terraform基础设施定义
module "frontend_infrastructure" {
  source = "./modules/frontend"
  
  environments = {
    dev     = { instance_count = 1, cdn_enabled = false }
    staging = { instance_count = 2, cdn_enabled = true }
    prod    = { instance_count = 5, cdn_enabled = true }
  }
}

GitOps部署模式：

# ArgoCD应用定义
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-app
spec:
  source:
    repoURL: https://github.com/company/config-repo
    path: frontend/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: frontend

监控和可观测性：

全链路监控：

• 构建监控： 构建时间、成功率、资源使用
• 部署监控： 部署进度、健康状态、回滚频率
• 业务监控： 用户体验指标、性能数据、错误率

告警和通知体系：

alerting:
  channels: ["slack", "email", "webhook"]
  rules:
    - name: "build_failure"
      condition: "build.status == 'failed'"
      severity: "high"
    - name: "deployment_slow"
      condition: "deployment.duration > 10m"
      severity: "medium"

团队协作架构：

• 权限分层： 基于角色的访问控制（RBAC）
• 审批流程： 关键环境部署需要审批
• 协作工具集成： 与Jira、Confluence等工具集成

扩展性考虑：

• 插件化架构： 支持自定义构建步骤和部署策略
• API优先： 提供完整的API支持自动化集成
• 多云支持： 支持多云环境和混合云部署

How to implement CI/CD for micro-frontend architecture?

• 考察点：微前端部署方案。

答案：

微前端架构的CI/CD实现需要处理多个独立应用的协调部署、版本管理、集成测试等复杂场景，构建支持团队自治和技术多样化的部署体系。

微前端CI/CD架构模式：

1. 独立部署模式（Independent Deployment）：

# 每个微前端独立流水线
micro_app_pipeline:
  trigger:
    - push: ["apps/user-management/**"]
  stages:
    - build_and_test:
        script: |
          cd apps/user-management
          npm install && npm test
          npm run build
    - deploy:
        script: |
          upload_to_cdn user-management $VERSION
          update_module_registry user-management $VERSION

2. 协调部署模式（Orchestrated Deployment）：

// 应用注册表管理
const moduleRegistry = {
  "user-management": {
    version: "1.2.3",
    url: "https://cdn.example.com/user-management/1.2.3/",
    teams: ["user-team"],
    dependencies: []
  },
  "order-system": {
    version: "2.1.0", 
    url: "https://cdn.example.com/order-system/2.1.0/",
    teams: ["order-team"],
    dependencies: ["[email protected]"]
  }
};

版本管理策略：

语义化版本控制：

{
  "name": "@company/user-management",
  "version": "1.2.3",
  "microfrontend": {
    "exposed": {
      "./UserProfile": "./src/UserProfile",
      "./UserList": "./src/UserList"
    },
    "shared": {
      "react": "^18.0.0",
      "react-dom": "^18.0.0"
    }
  }
}

依赖管理：

# 共享依赖检查
dependency_check:
  script: |
    check_shared_dependencies
    validate_peer_dependencies
    generate_dependency_graph

构建和打包策略：

Module Federation构建：

// webpack.config.js 微前端配置
const ModuleFederationPlugin = require('@module-federation/webpack');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'userManagement',
      filename: 'remoteEntry.js',
      exposes: {
        './UserProfile': './src/components/UserProfile',
        './UserList': './src/components/UserList'
      },
      shared: {
        react: { singleton: true, eager: true },
        'react-dom': { singleton: true, eager: true }
      }
    })
  ]
};

独立构建优化：

# 多阶段构建支持多个微前端
FROM node:18-alpine AS base
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM base AS user-app
COPY apps/user-management ./
RUN npm run build

FROM base AS order-app  
COPY apps/order-system ./
RUN npm run build

FROM nginx:alpine
COPY --from=user-app /app/dist /usr/share/nginx/html/user-management
COPY --from=order-app /app/dist /usr/share/nginx/html/order-system

集成测试策略：

契约测试：

// Pact契约测试
describe('User Service Contract', () => {
  it('should provide user data in expected format', () => {
    return provider
      .given('user exists')
      .uponReceiving('get user request')
      .withRequest({
        method: 'GET',
        path: '/api/user/123'
      })
      .willRespondWith({
        status: 200,
        body: { id: 123, name: 'John Doe' }
      });
  });
});

端到端集成测试：

e2e_integration:
  script: |
    # 部署所有微前端到测试环境
    deploy_all_microfrontends_to_staging
    # 运行跨应用集成测试
    npm run test:e2e:integration
    # 验证模块间通信
    npm run test:module-communication

部署编排策略：

渐进式部署：

progressive_deployment:
  stages:
    - deploy_core_shell:
        script: deploy_main_app $MAIN_VERSION
    - deploy_microfrontends:
        parallel:
          - deploy_microapp user-management $USER_VERSION
          - deploy_microapp order-system $ORDER_VERSION  
          - deploy_microapp analytics $ANALYTICS_VERSION
    - integration_verification:
        script: verify_all_modules_loaded

蓝绿部署适配：

// 微前端蓝绿部署
const deploymentStrategy = {
  type: 'blue-green',
  modules: {
    'user-management': { 
      blue: 'v1.2.3', 
      green: 'v1.3.0' 
    },
    'order-system': { 
      blue: 'v2.1.0', 
      green: 'v2.1.0' 
    }
  }
};

监控和可观测性：

模块级监控：

// 微前端性能监控
const moduleMetrics = {
  loadTime: performance.mark('module-load-end') - performance.mark('module-load-start'),
  errorRate: errorCount / totalRequests,
  bundleSize: getBundleSize('user-management'),
  dependencies: getLoadedDependencies()
};

集成监控：

monitoring:
  module_health:
    - name: "module_load_success"
      query: "sum(module_load_success_total) by (module_name)"
    - name: "cross_module_communication"
      query: "sum(module_communication_errors_total)"

回滚策略：

模块级回滚：

# 单个微前端回滚
rollback_microfront user-management --to-version=1.2.2
# 验证其他模块兼容性
verify_module_compatibility user-management 1.2.2

级联影响分析：

// 回滚影响评估
const rollbackImpact = {
  targetModule: 'user-management',
  fromVersion: '1.3.0',
  toVersion: '1.2.3',
  affectedModules: ['analytics', 'notification'],
  compatibilityCheck: 'passed'
};

最佳实践：

• 建立清晰的模块边界和接口契约
• 实现细粒度的部署和回滚机制
• 强化跨模块集成测试
• 建立统一的监控和告警体系
• 制定模块升级和废弃策略

What are the security considerations and implementations in CI/CD?

• 考察点：DevSecOps理念。

答案：

CI/CD安全性（DevSecOps）是将安全实践融入到开发和运维流程中的重要理念，通过自动化安全检测、权限管理、合规审计等手段确保软件供应链的安全性。

安全威胁模型：

供应链安全威胁：

• 恶意依赖包： 第三方库被植入恶意代码
• 构建环境污染： 构建服务器被入侵
• 制品篡改： 部署包在传输过程中被修改
• 权限滥用： 内部人员权限过大导致的安全风险

CI/CD流程安全实现：

1. 代码安全检查（SAST - Static Application Security Testing）：

security_scan:
  stage: security
  script: |
    # 静态代码安全扫描
    sonar-scanner -Dsonar.projectKey=frontend-app
    # 依赖安全扫描  
    npm audit --audit-level high
    snyk test --severity-threshold=medium
    # 敏感信息扫描
    gitleaks detect --source .

2. 依赖安全管理：

// package.json 安全配置
{
  "scripts": {
    "audit:dependencies": "audit-ci --moderate",
    "audit:licenses": "license-checker --onlyAllow 'MIT;Apache-2.0;BSD-3-Clause'"
  },
  "audit-ci": {
    "moderate": true,
    "allowlist": [],
    "report-type": "full"
  }
}

3. 容器安全扫描：

# 安全基础镜像选择
FROM node:18-alpine AS base
# 非root用户运行
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nextjs -u 1001

# 多阶段构建减少攻击面
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

FROM base AS runner
WORKDIR /app
COPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules
USER nextjs

权限和访问控制：

基于角色的访问控制（RBAC）：

# CI/CD权限配置
permissions:
  developers:
    - read: ["source-code", "build-logs"]
    - write: ["feature-branches"]
  
  maintainers:
    - read: ["all"]
    - write: ["main-branch", "release-tags"]
    - deploy: ["staging"]
  
  ops_team:
    - read: ["all"]
    - deploy: ["production"]
    - rollback: ["all-environments"]

密钥管理：

# 安全密钥注入
deploy:
  script: |
    export API_KEY=$(vault kv get -field=key secret/api-keys)
    export DB_PASSWORD=$(kubectl get secret db-secret -o jsonpath='{.data.password}' | base64 -d)
    deploy_application
  only:
    - main

构建环境安全：

隔离的构建环境：

# 使用ephemeral runners
build:
  runs-on: ubuntu-latest
  container:
    image: node:18-alpine
    options: --user 1001 --security-opt no-new-privileges
  steps:
    - name: Checkout with token
      uses: actions/checkout@v4
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        persist-credentials: false

网络安全控制：

# 网络访问限制
network_policy:
  build_stage:
    allowed_egress:
      - npm_registry: "registry.npmjs.org"
      - github: "github.com"
    blocked_egress:
      - internal_networks: "10.0.0.0/8"

制品安全：

签名和验证：

# 构建制品签名
sign_artifacts() {
  cosign sign --key env://COSIGN_PRIVATE_KEY \
    $DOCKER_REGISTRY/app:$VERSION
}

# 部署时验证
verify_artifacts() {
  cosign verify --key cosign.pub \
    $DOCKER_REGISTRY/app:$VERSION
}

制品扫描：

artifact_security:
  script: |
    # Docker镜像安全扫描
    trivy image --severity HIGH,CRITICAL $IMAGE_TAG
    # 文件完整性检查
    sha256sum dist/*.js > checksums.txt
    gpg --sign checksums.txt

合规性和审计：

审计日志：

{
  "timestamp": "2025-01-15T10:30:00Z",
  "event": "deployment",
  "user": "[email protected]", 
  "environment": "production",
  "artifact": "app:v1.2.3",
  "approval": "APPROVED-2025-001",
  "status": "success"
}

合规检查：

compliance_check:
  script: |
    # PCI DSS合规检查
    check_pci_compliance
    # GDPR数据处理合规
    validate_data_processing_consent
    # SOC2合规验证  
    run_soc2_controls_validation

安全监控和响应：

实时威胁检测：

security_monitoring:
  triggers:
    - suspicious_dependency_add
    - unauthorized_secret_access
    - abnormal_build_behavior
  
  responses:
    - block_deployment
    - notify_security_team
    - trigger_incident_response

入侵检测：

// 异常行为检测
const securityChecks = {
  detectAnomalousBuilds: () => {
    // 检测异常的构建行为
    if (buildTime > averageBuildTime * 3) {
      alertSecurityTeam('Anomalous build duration detected');
    }
  },
  
  validateArtifactIntegrity: () => {
    // 验证制品完整性
    const currentHash = calculateHash(artifact);
    if (currentHash !== expectedHash) {
      blockDeployment('Artifact integrity check failed');
    }
  }
};

安全事件响应：

• 自动阻断： 检测到威胁时自动停止流水线
• 事件上报： 安全事件自动通知安全团队
• 取证支持： 保留详细的操作和审计日志
• 快速恢复： 建立安全事件快速响应和恢复机制

最佳实践：

• 实施"最小权限原则"，按需分配权限
• 定期进行安全审计和渗透测试
• 建立安全培训和意识提升计划
• 制定安全事件应急响应预案
• 持续更新安全策略应对新威胁

CI/CD是提高开发效率和代码质量的重要实践，需要根据项目规模和团队情况制定合适的策略。