19 | 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障

// k6/performance-test.js
import { check } from 'k6';
import http from 'k6/http';

export const options = {
  stages: [
    { duration: '30s', target: 10 },   // 预热
    { duration: '1m', target: 50 },     // 正常负载
    { duration: '20s', target: 100 },   // 高负载
    { duration: '20s', target: 200 },   // 峰值负载
    { duration: '30s', target: 0 },     // 恢复
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],  // P95 < 500ms, P99 < 1s
    http_req_failed: ['rate<0.01'],                     // 错误率 < 1%
  },
};

const BASE_URL = __ENV.BASE_URL || 'https://staging.api.internal';

export default function () {
  const res = http.get(`${BASE_URL}/api/products`);
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
}

# .github/workflows/security.yml
name: Security Scan
on:
  push:
    branches: [main]
  pull_request:

jobs:
  # SAST - 静态应用安全测试
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: go
      - name: Perform Analysis
        uses: github/codeql-action/analyze@v3

  # SCA - 软件组件分析
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  # Container Scanning
  container-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Run Trivy image scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'ghcr.io/org/my-app:latest'  # 示例：替换为实际待扫描镜像
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

# chaos-pod-kill.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-experiment
  namespace: production
spec:
  action: pod-kill
  mode: one       # 随机选择一个pod
  selector:
    labelSelectors:
      app: my-app
  scheduler:
    cron: '@every 10m'  # 每10分钟执行一次

# .github/branch-protection-rules.yml (通过CLI设置)
# 或者直接在GitHub Settings > Branches中配置
Required status checks:
  - ci/lint-format     # Lint + Format检查
  - ci/unit-tests      # 单元测试
  - ci/security-scan   # 安全扫描
  - ci/integration     # 集成测试
  - ci/performance     # 性能回归检测

Required signatures:  # 需要CODEOWNER审批
  - CODEOWNERS file defines reviewers

Strict: true  # 必须在最新的commit上通过

❌ 陷阱1："测试全是UI自动化E2E"
   症状：所有测试都是E2E，运行一次要几小时
   根因：不理解测试金字塔，过度依赖E2E
   后果：反馈极慢，维护成本高，flaky test多
   解法：遵循测试金字塔，大量单元+少量集成+极少量E2E

❌ 陷阱2:"测试只走Happy Path"
   症状：正常流程都过了,异常场景一上线就挂
   根因：只测试了预期内的操作
   后果：边界条件和异常处理是bug的主要来源
   解法：表格驱动测试 + 属性-based testing + 模糊测试

❌ 陷阱3:"Flaky Test泛滥"
   症状：同样的测试时而通过时而失败
   根因：测试之间有依赖、异步竞态、硬编码等待
   后果：团队不再信任测试结果,最终关闭告警
   解法：隔离测试 + 合理的retry + flaky test自动标记+修复SLA

❌ 陷阱4:"性能测试只在上线前做一次"
   症状：上线后发现性能退化
   根因：没有建立持续的性能基线和回归检测
   后果：性能问题发现太晚,回滚成本高
   解法：每次CI都跑轻量级性能测试 + 定期完整压测

❌ 陷阱5:"安全测试是安全团队的事"
   症状：开发阶段不考虑安全问题
   根因：认为安全是别人的责任
   后果：漏洞在后期发现,修复成本指数级上升
   解法：安全左移,每个工程师都对安全负责

❌ 陷阱6:"混沌工程不敢在生产做"
   症状：混沌工程只在测试环境做
   根因：担心影响生产
   后果：测试环境的混沌结果不能代表生产
   解法：从小规模开始(杀一个Pod),逐步扩大范围,建立信心