DevOps & 工程化

难度等级：⭐⭐⭐ 前置知识：Web 后端开发 后续衔接：微服务架构、云原生

学习路径

一、CI/CD 持续集成与交付

1.1 CI/CD 概念

CI/CD 是现代软件工程中不可或缺的核心实践，它将传统的”开发完成后一次性交付”模式转变为高频、小批量的持续交付模式。

持续集成（Continuous Integration, CI） 是指开发人员频繁地将代码变更合并到主干分支，每次合并都会触发自动化构建和测试流程。其核心目标是尽早发现集成错误，避免”集成地狱”。典型的 CI 流程包括：代码提交 → 触发构建 → 编译打包 → 运行单元测试 → 运行集成测试 → 生成构建报告。

持续交付（Continuous Delivery, CD） 在 CI 的基础上，确保代码在任何时候都可以安全地部署到生产环境。它强调自动化部署流程，但最终是否上线由人工决定。持续交付的关键环节包括：自动化部署到预发环境 → 运行验收测试 → 性能测试 → 安全扫描 → 等待人工审批。

持续部署（Continuous Deployment） 是持续交付的更进一步，所有通过自动化测试的变更都会自动部署到生产环境，无需人工干预。这需要极高的测试覆盖率和成熟的监控体系作为保障。

三者关系可以用一句话概括：持续集成是基础，持续交付是保障，持续部署是目标。

实践 自动化测试 人工审批 生产部署
持续集成 ✅ ❌ ❌
持续交付 ✅ ✅ 手动触发
持续部署 ✅ ❌ 自动触发

1.2 Jenkins

Jenkins 是最流行的开源 CI/CD 工具，拥有超过 1800 个插件，支持几乎任何构建、测试和部署场景。

Pipeline 语法：Jenkins Pipeline 使用 Groovy 语言定义，分为声明式（Declarative）和脚本式（Scripted）两种。推荐使用声明式，结构更清晰：

pipeline {
    agent any
    environment {
        DOCKER_REGISTRY = 'registry.example.com'
    }
    stages {
        stage('Checkout') {
            steps { checkout scm }
        }
        stage('Build') {
            steps { sh './gradlew build' }
        }
        stage('Test') {
            parallel {
                stage('Unit Tests') { steps { sh './gradlew test' } }
                stage('Integration Tests') { steps { sh './gradlew integrationTest' } }
            }
        }
        stage('Deploy') {
            when { branch 'main' }
            steps { sh './deploy.sh' }
        }
    }
    post {
        success { echo 'Pipeline succeeded!' }
        failure { mail to: 'team@example.com', subject: 'Pipeline Failed' }
    }
}

Jenkinsfile 应该与源代码一起提交到版本控制系统中，实现 Pipeline as Code。这样既便于版本管理，也方便团队协作。

分布式构建：Jenkins 支持 Master-Agent 架构，可以将构建任务分发到多个 Agent 节点，提高并发构建能力。配置 Agent 时需要指定标签（label），Pipeline 中通过 agent { label 'linux' } 指定运行节点。

插件生态：常用插件包括 Git Plugin、Docker Plugin、Kubernetes Plugin、SonarQube Scanner、Blue Ocean（可视化 Pipeline）等。插件过多会影响 Jenkins 性能，建议只安装必要的插件。

1.3 GitLab CI

GitLab CI 与 GitLab 代码仓库深度集成，无需额外部署独立服务，配置简洁。

核心概念：

.gitlab-ci.yml 示例：

stages:
  - build
  - test
  - deploy

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

cache:
  paths:
    - .m2/repository/

build-job:
  stage: build
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 week

test-job:
  stage: test
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn test
  coverage: '/Coverage: \d+\.\d+%/'

deploy-job:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - main

Runner 类型：Shared Runner（所有项目共享）、Group Runner（组内共享）、Specific Runner（绑定特定项目）。Runner 执行器支持 Docker、Shell、Kubernetes 等多种模式。

优化技巧：

1.4 GitHub Actions

GitHub Actions 是 GitHub 内置的 CI/CD 工具，与 GitHub 生态无缝集成，拥有庞大的 Action 市场。

核心概念：

Workflow 示例：

name: CI Pipeline

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java: ['17', '21']
      fail-fast: false
    steps:
      - uses: actions/checkout@v4
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          java-version: ${{ matrix.java }}
          distribution: 'temurin'
          cache: 'gradle'
      - name: Build
        run: ./gradlew build
      - name: Upload Test Results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results-java-${{ matrix.java }}
          path: build/reports/tests/

  docker-build:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Matrix 构建 允许在多个维度上并行执行任务，如不同操作系统、不同语言版本、不同数据库版本等，非常适合兼容性测试。

Secrets 管理：敏感信息（如 API Key、Docker 密码）应存储在 Repository Settings → Secrets 中，通过 ${{ secrets.NAME }} 在 Workflow 中引用。

1.5 自动化测试

自动化测试是 CI/CD 的基石，没有可靠的测试体系，持续集成就失去了意义。

测试金字塔（Test Pyramid）由 Mike Cohn 提出，建议测试分为三层：

        /\
       /  \    E2E Tests（端到端测试）- 少量
      /____\
     /      \   Integration Tests（集成测试）- 适量
    /________\
   /          \  Unit Tests（单元测试）- 大量
  /____________\

测试策略建议：

常见测试框架：

1.6 代码质量

代码质量是软件可维护性的保障，需要通过工具化手段在 CI/CD 流程中自动检查。

SonarQube 是最流行的代码质量管理平台，支持 30+ 编程语言。它能检测：

SonarQube 集成示例：

# GitLab CI 中集成 SonarQube
sonarqube-check:
  stage: test
  image: sonarsource/sonar-scanner-cli:latest
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
    GIT_DEPTH: "0"
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - sonar-scanner
      -Dsonar.projectKey=${CI_PROJECT_NAME}
      -Dsonar.qualitygate.wait=true
  allow_failure: true
  only:
    - merge_requests
    - main

代码规范检查：

质量门禁（Quality Gate） 建议配置：

二、容器化

2.1 Docker 基础

Docker 通过容器技术实现了应用的标准化打包和隔离运行，是云原生时代的基石。

镜像（Image）与容器（Container）：镜像是只读的模板，包含运行应用所需的代码、运行时、库和配置。容器是镜像的运行实例，具有独立的文件系统、网络命名空间和进程空间。可以把镜像理解为”类”，容器理解为”对象”。

Dockerfile 常用指令：

# 基础镜像
FROM eclipse-temurin:17-jre-alpine

# 设置工作目录
WORKDIR /app

# 设置环境变量
ENV JAVA_OPTS="-Xmx512m -Xms256m"

# 复制文件
COPY target/app.jar app.jar

# 暴露端口
EXPOSE 8080

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:8080/actuator/health || exit 1

# 启动命令
ENTRYPOINT ["java", "-jar", "app.jar"]

Dockerfile 指令说明：

层（Layer）与缓存：Docker 镜像由多个只读层叠加而成。每条指令创建一个层。Docker 会缓存已构建的层，如果某层内容未变，则复用缓存。因此应将变化频率低的指令（如安装依赖）放在前面，变化频率高的指令（如复制源码）放在后面，以充分利用缓存加速构建。

2.2 Docker Compose

Docker Compose 用于定义和运行多容器应用，通过一个 YAML 文件管理所有容器的生命周期。

docker-compose.yml 示例：

version: '3.8'

services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=docker
      - DB_HOST=db
      - REDIS_HOST=redis
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - app-network

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: appdb
    volumes:
      - db-data:/var/lib/mysql
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - app-network

  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - app-network

volumes:
  db-data:
  redis-data:

networks:
  app-network:
    driver: bridge

核心概念：

常用命令：

2.3 镜像优化

镜像优化直接影响构建速度、传输效率和运行时安全性。

多阶段构建（Multi-stage Build） 是最有效的优化手段，将构建环境和运行环境分离：

# 构建阶段
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests -q

# 运行阶段
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# 仅复制构建产物，不包含源码和 Maven
COPY --from=builder /build/target/*.jar app.jar
USER appuser
ENTRYPOINT ["java", "-jar", "app.jar"]

优化策略：

  1. 选择精简基础镜像：优先使用 Alpine 或 Distroless 镜像。Alpine 基于 musl libc，体积仅 5MB；Distroless 仅包含运行时依赖，无 shell 和包管理器。
  2. 合并 RUN 指令：将多个 apt-get 命令合并为一条，减少镜像层数。
  3. 使用 .dockerignore：排除不必要的文件（如 .git、node_modules、target），减小构建上下文。
  4. 利用构建缓存：将变化少的层（如依赖安装）放在前面，变化多的层（如源码复制）放在后面。
  5. 清理临时文件：在同一层中安装依赖后立即清理缓存，如 apt-get clean && rm -rf /var/lib/apt/lists/*。

.dockerignore 示例：

.git
.gitignore
.idea
*.md
target/
build/
node_modules/
.env
.dockerignore
Dockerfile
docker-compose*.yml

镜像大小对比：

2.4 容器安全

容器安全是生产环境中不可忽视的环节。

以非 root 用户运行：默认情况下，容器内的进程以 root 身份运行，一旦被攻破，攻击者可能获得宿主机权限。

# 创建非 root 用户
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
# 设置文件权限
RUN chown -R appuser:appgroup /app
# 切换用户
USER appuser

镜像扫描：定期扫描镜像中的已知漏洞（CVE）。常用工具包括 Trivy、Grype、Snyk、Docker Scout。

# 使用 Trivy 扫描镜像
trivy image --severity HIGH,CRITICAL myapp:latest

Secret 管理：

其他安全最佳实践：

三、Kubernetes

3.1 K8s 架构

Kubernetes（简称 K8s）是 Google 开源的容器编排平台，已成为云原生时代的事实标准。

控制平面（Control Plane / Master 节点）：

工作节点（Worker Node / Node）：

架构特点：声明式 API（用户声明期望状态，控制器自动趋近目标）、自愈能力（自动重启、替换失败的 Pod）、水平扩展（通过增加 Node 提升集群容量）。

3.2 核心资源

Pod：K8s 最小的部署单元，包含一个或多个容器。同一 Pod 内的容器共享网络命名空间（同一个 IP）和存储卷。

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
  labels:
    app: myapp
    version: v1
spec:
  containers:
    - name: app
      image: myapp:1.0.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"
      livenessProbe:
        httpGet:
          path: /actuator/health/liveness
          port: 8080
        initialDelaySeconds: 30
        periodSeconds: 10
      readinessProbe:
        httpGet:
          path: /actuator/health/readiness
          port: 8080
        initialDelaySeconds: 10
        periodSeconds: 5

Deployment：管理 Pod 的副本数量，支持滚动更新和回滚。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:1.0.0

Service：为一组 Pod 提供稳定的网络访问入口，通过 Label Selector 关联 Pod。

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

ConfigMap 和 Secret：

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  application.yml: |
    server:
      port: 8080
    spring:
      datasource:
        url: jdbc:mysql://db:3306/appdb
---
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  db-password: cm9vdDEyMw==  # base64 encoded

3.3 服务暴露

K8s 提供了多种服务暴露方式，适用于不同场景。

类型 说明 使用场景
ClusterIP 集群内部可访问的虚拟 IP（默认） 内部服务间通信
NodePort 在每个 Node 上开放指定端口 开发测试、简单外部访问
LoadBalancer 调用云提供商创建外部负载均衡器 生产环境，云部署
Ingress 七层 HTTP/HTTPS 路由，基于域名和路径转发 多域名、多路径路由

Ingress 示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: tls-secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: app-v1-service
                port:
                  number: 80
          - path: /v2
            pathType: Prefix
            backend:
              service:
                name: app-v2-service
                port:
                  number: 80

Ingress 需要配合 Ingress Controller（如 Nginx Ingress、Traefik、Istio Gateway）才能工作。

3.4 存储

K8s 的存储体系分为三层抽象：

PersistentVolume（PV）：集群级别的存储资源，由管理员预先创建或由 StorageClass 动态创建。

PersistentVolumeClaim（PVC）：用户对存储的请求，类似于 Pod 对 Node 资源的请求。系统会将 PVC 与合适的 PV 绑定。

StorageClass：定义存储的”类型”，支持动态供应（Dynamic Provisioning）。

# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
---
# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 50Gi
---
# Pod 中使用 PVC
# 在 Pod spec 中：
volumes:
  - name: db-storage
    persistentVolumeClaim:
      claimName: db-pvc

访问模式：

3.5 自动扩缩容

K8s 提供了多层次的自动扩缩容能力。

HPA（Horizontal Pod Autoscaler）：根据 CPU、内存或自定义指标自动调整 Pod 副本数。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Pods
          value: 2
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300

VPA（Vertical Pod Autoscaler）：自动调整 Pod 的 CPU 和内存请求/限制。适合无法水平扩展的有状态应用。

Cluster Autoscaler：当 Pod 因资源不足无法调度时，自动增加 Node 数量；当 Node 利用率过低时，自动缩减 Node。需要云提供商支持。

KEDA（Kubernetes Event-driven Autoscaling）：基于外部事件源（如消息队列长度、HTTP 请求数）驱动扩缩容，适合事件驱动架构。

3.6 Helm

Helm 是 K8s 的包管理工具，通过模板化方式管理复杂的 K8s 资源。

Chart 结构：

mychart/
├── Chart.yaml          # Chart 元数据（名称、版本、描述）
├── values.yaml         # 默认配置值
├── values-prod.yaml    # 环境特定配置
├── charts/             # 依赖的子 Chart
└── templates/          # K8s 资源模板
    ├── deployment.yaml
    ├── service.yaml
    ├── configmap.yaml
    └── ingress.yaml

模板中使用 Values：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mychart.fullname" . }}
  labels:
    {{- include "mychart.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "mychart.name" . }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

常用命令：

四、监控与日志

4.1 Prometheus

Prometheus 是云原生时代最流行的监控系统，采用拉模式（Pull）采集指标。

数据模型：Prometheus 将所有数据存储为时间序列（Time Series），由指标名称和键值对标签组成。例如：http_requests_total{method="POST", handler="/api/users", status="200"}。

四种指标类型：

Exporter：将非 Prometheus 格式的数据转换为 Prometheus 格式。常用 Exporter 包括：

PromQL 示例：

# 过去 5 分钟的 HTTP 请求速率（每秒）
rate(http_requests_total[5m])

# P99 请求延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# 错误率（5xx 响应占比）
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# 内存使用率
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

AlertManager：负责处理 Prometheus 产生的告警，支持分组、抑制、静默和多渠道通知（邮件、Slack、钉钉、企业微信、PagerDuty）。

4.2 Grafana

Grafana 是最流行的可视化仪表盘工具，支持多种数据源。

核心功能：

典型 Dashboard 布局：

  1. 顶部：关键指标概览（QPS、错误率、延迟、饱和度）
  2. 中部：各服务的详细指标（请求量、响应时间、资源使用）
  3. 底部：基础设施指标（CPU、内存、磁盘、网络）

Grafana + Prometheus 告警规则示例：

# prometheus-rule.yml
groups:
  - name: app-alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "高错误率：{{ $value | humanizePercentage }}"
          description: "服务 {{ $labels.job }} 的 5xx 错误率超过 5%"

4.3 ELK 日志栈

ELK（Elasticsearch + Logstash + Kibana）是经典的日志管理方案，现在常与 Filebeat 配合使用，称为 Elastic Stack。

架构组件：

应用 → Filebeat → Logstash → Elasticsearch → Kibana
       (采集)      (处理)       (存储)         (展示)

Filebeat：轻量级日志采集器，部署在每台主机上，负责读取日志文件并发送到 Logstash 或 Elasticsearch。

# filebeat.yml
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/app/*.log
    fields:
      service: myapp
      env: production
    multiline:
      pattern: '^\d{4}-\d{2}-\d{2}'
      negate: true
      match: after

output.logstash:
  hosts: ["logstash:5044"]

Logstash：日志处理管道，支持过滤、转换、丰富日志数据。

# logstash.conf
input {
  beats { port => 5044 }
}
filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} \[%{LOGLEVEL:level}\] %{DATA:logger} - %{GREEDYDATA:msg}" }
  }
  date {
    match => ["timestamp", "yyyy-MM-dd HH:mm:ss.SSS"]
  }
  mutate {
    remove_field => ["timestamp"]
  }
}
output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "app-logs-%{+YYYY.MM.dd}"
  }
}

Elasticsearch：分布式搜索引擎，负责存储和索引日志数据。需要关注索引生命周期管理（ILM），定期滚动索引以控制存储成本。

Kibana：日志可视化工具，支持搜索、过滤、聚合分析和创建 Dashboard。

4.4 链路追踪

链路追踪用于追踪请求在分布式系统中的完整调用路径，帮助定位性能瓶颈和故障根因。

核心概念：

OpenTelemetry：CNCF 的观测性标准，统一了链路追踪、指标和日志的采集方式。

# OpenTelemetry Collector 配置示例
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true
  logging:
    loglevel: debug

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger, logging]

主流追踪后端：

链路追踪的价值：

4.5 可观测性三位一体

现代云原生系统的可观测性建立在三个支柱之上：

Metrics（指标）：聚合的数值数据，如 CPU 使用率、QPS、错误率。特点是存储效率高，适合趋势分析和告警，但无法提供单个请求的详细信息。

Logs（日志）：离散的事件记录，包含时间戳、级别、消息等。特点是信息丰富、可搜索，但存储成本高，难以直接关联。

Traces（链路追踪）：请求级别的调用路径记录。特点是能完整还原请求生命周期，但采样率高时可能遗漏问题。

三者的关系：

用户请求 → [Trace] 完整调用链路
              ↓
         每个 Span 关联 → [Logs] 该步骤的详细日志
              ↓
         每个服务暴露 → [Metrics] 聚合指标

整合实践：

五、版本控制与协作

5.1 Git 工作流

Git 工作流定义了团队协作开发时的分支策略和代码合并规范。

Git Flow：经典的双主干模型，适合有固定发布周期的项目。

main (生产) ──────────────────────────────────────
     ↑           ↑              ↑
  release/1.0  release/1.1   release/2.0
     ↑           ↑              ↑
develop ──────────────────────────────────────────
  ↑    ↑         ↑
  │    └─ feature/B
  └─ feature/A

GitHub Flow：简化的单主干模型，适合持续部署。

main ───┬────────────────────────────────────────
        │    ┌─ feature/A (PR) ──┐
        │    │                   │
        └────┴───────────────────┘── deploy

Trunk Based Development：所有开发者直接向主干提交代码（或小批量短分支），配合功能开关（Feature Flags）控制功能可见性。适合高频发布的团队。

5.2 分支策略

分支策略的选择取决于团队的发布频率和质量要求。

保护分支（Protected Branches）：

分支命名规范：

合并策略：

5.3 Code Review

Code Review 是保证代码质量、知识共享和团队一致性的重要实践。

Review 清单：

Review 最佳实践：

5.4 语义化提交

Conventional Commits 规范了提交信息的格式，使提交历史更具可读性和可自动化处理。

格式：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

常用 type：

示例：

feat(auth): add JWT token refresh endpoint

Implements token refresh to allow users to extend
their session without re-authentication.

Closes #123

自动化工具：

六、学习资源推荐

CI/CD

容器化

Kubernetes

监控与日志

版本控制