RyB 知识库

CI/CD 与 DevOps 学习笔记

从代码提交到生产发布，系统理解持续集成、持续交付与 DevOps 实践。

1 · DevOps 文化与流程

1.1 什么是 DevOps

DevOps = Development + Operations。

它不是某个岗位，而是一套文化和实践：

  • 开发团队和运维团队协同工作
  • 自动化一切能自动化的步骤
  • 频繁、小批量、低风险地发布
  • 出了问题先修复，再复盘改进

1.2 DevOps 的核心理念

自动化

  • 手动操作容易出错，且不可重复
  • 构建、测试、部署、监控都应自动化

基础设施即代码（IaC）

  • 服务器配置、网络、数据库用代码管理
  • 工具：Terraform、Ansible、Pulumi、CloudFormation

小步快跑

  • 小批量变更更容易回滚和定位问题
  • 频繁发布降低单次发布风险

可观测性

  • 日志（Logging）、指标（Metrics）、链路追踪（Tracing）三位一体

Blameless 文化

  • 故障复盘不追责，关注系统如何改进

1.3 CI/CD 流水线

图 1 \xb7 CI/CD 流水线

2 · Git 工作流

2.1 常见分支模型

Git Flow

  • master：生产分支
  • develop：开发分支
  • feature/*：功能分支
  • release/*：发布分支
  • hotfix/*：紧急修复分支
  • 适合：版本发布型项目，发布周期较长

GitHub Flow

  • main：主分支
  • feature branch：功能分支
  • 提交 PR → Review → 合并到 main
  • 适合：持续部署、Web 应用

Trunk-Based Development

  • 所有人都向 main 分支提交
  • feature 分支短命，不超过 1-2 天
  • 配合 feature flag 控制功能上线
  • 适合：高频发布的大型团队

2.2 Code Review

Code Review 不只是挑错，更是知识共享和架构对齐。

关注点：

  • 逻辑正确性
  • 边界条件
  • 可读性（命名、注释、复杂度）
  • 安全漏洞
  • 性能问题
  • 测试覆盖

建议：

  • PR 尽量小，300 行以内为佳
  • 提交信息写清楚改动背景和原因
  • Reviewer 提出问题要说明理由

2.3 提交规范

Conventional Commits：

feat: 新增用户登录功能 fix: 修复订单金额计算错误 docs: 更新 API 文档 refactor: 重构支付模块 test: 添加订单模块单元测试 chore: 升级依赖版本

配合语义化版本号：

  • feat → MINOR 版本
  • fix → PATCH 版本
  • BREAKING CHANGE → MAJOR 版本

3 · GitHub Actions

3.1 工作流文件

放在 .github/workflows/ 目录下。

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm run build
      - run: npm test

3.2 核心概念

  • Workflow：一个 YAML 文件
  • Job：一组 Step，可以并行或依赖执行
  • Step：具体命令或 Action
  • Action：可复用的步骤单元
  • Runner：执行环境，GitHub 托管或自托管
  • Matrix：多环境测试（多个 OS、多个语言版本）

3.3 常用技巧

缓存依赖：

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('**/package-lock.json') }}

制品上传：

- uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/

3.4 Gitee Go

Gitee 的 CI/CD 服务，语法类似 GitHub Actions：

stages:
  - build
  - test
  - deploy

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

4 · Jenkins Pipeline

4.1 Jenkinsfile

用代码定义流水线，纳入版本管理。

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'npm ci && npm run build'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
        stage('Deploy') {
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        always {
            cleanWs()
        }
        failure {
            mail to: 'team@example.com', subject: 'Build Failed'
        }
    }
}

4.2 声明式 vs 脚本式

  • 声明式：结构化，适合简单流水线
  • 脚本式：用 Groovy 脚本，灵活但复杂

4.3 Jenkins vs GitHub Actions

特性 Jenkins GitHub Actions
部署方式 自托管 云端 / 自托管
维护成本 高 低
插件生态 丰富 Marketplace Actions
与代码仓库集成 需配置 webhook 原生集成
适合 企业内部复杂流水线 云原生开源项目

5 · 自动化测试

5.1 测试金字塔

/ E2E \ 少量，慢，覆盖广 / 集成测试 \ 中等 / 单元测试 \ 大量，快，成本低

5.2 单元测试

测试最小单元（函数、类）的逻辑。

原则：

  • 一个测试只验证一个概念
  • 输入简单，断言明确
  • Mock 外部依赖

Python 示例：

import pytest

def add(a, b):
    return a + b

def test_add():
    assert add(1, 2) == 3
    assert add(-1, 1) == 0

5.3 集成测试

测试模块之间的协作。

工具：

  • Testcontainers：用 Docker 启动真实依赖（MySQL、Redis、Kafka）
  • Spring Boot Test
  • pytest + Docker Compose

5.4 E2E 测试

模拟用户真实操作流程。

工具：

  • Playwright：微软出品，支持多浏览器
  • Cypress：前端友好
  • Selenium：老牌，生态丰富

注意：

  • E2E 测试脆弱，容易因为 UI 变化失败
  • 只覆盖核心用户路径
  • 避免过度依赖 E2E

6 · 制品与镜像管理

6.1 制品类型

  • 编译产物：jar、二进制、npm 包
  • Docker 镜像
  • Helm Chart

6.2 镜像仓库

  • Harbor：开源企业级镜像仓库，支持镜像扫描、签名
  • Nexus / Artifactory：通用制品仓库
  • GitHub Packages / GitLab Container Registry
  • 云厂商 ACR / TCR / ECR

6.3 Docker 镜像最佳实践

多阶段构建：

FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

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

其他建议：

  • 使用特定版本 tag，不用 latest
  • 使用 .dockerignore 减少构建上下文
  • 非 root 用户运行
  • 定期扫描镜像漏洞

7 · 发布与回滚

7.1 发布策略

蓝绿部署

  • 两套环境：蓝色（旧）、绿色（新）
  • 流量一次性切到绿色
  • 出问题瞬间切回蓝色
  • 缺点：资源翻倍

金丝雀发布

  • 先让 1% 流量到新版本
  • 观察指标无异常后逐步扩大比例
  • 适合：大规模用户、风险较高的发布

滚动发布

  • 逐个替换实例
  • K8s Deployment 默认行为
  • 资源占用平稳，但回滚较慢

7.2 回滚

  • K8s：kubectl rollout undo deployment/xxx
  • Docker：切回旧镜像 tag
  • 数据库变更：必须可回滚，提供 down 迁移脚本

7.3 灰度指标

发布过程中重点观察：

  • 错误率
  • P99 延迟
  • CPU / 内存使用率
  • 业务关键指标（下单成功率、支付成功率）

7.4 可观测性

支柱 说明 工具
日志 离散事件记录 ELK、Loki
指标 聚合数值 Prometheus + Grafana
链路追踪 请求全链路 Jaeger、SkyWalking

告警设计原则：

  • 分级：P0 ~ P3
  • 避免告警风暴
  • 每个告警都应有对应处理手册
本页目录