预览环境与临时环境治理：Environment as Code 与 PR 级验证

传统验证方式的痛点：
  - 本地联调：依赖不齐、无法测真实集成
  - 共享 dev 环境：互相干扰，改一个坏一片
  - E2E 只能在合并前/后跑一次，反馈太晚

预览环境的定位：
  每个 PR 一个"真实部署、真实数据、可访问 URL"的隔离环境
  → 开发者/QA/产品都能在合并前"亲手验"

方式一：静态模板 + 参数（最常见）
  一套 Helm/Compose/Kustomize 模板，按 PR 参数化渲染

方式二：完全声明式（GitOps 式）
  环境清单在 Git 里，PR 触发一个"环境 CRD/分支"，
  由控制器自动生成一套

方式三：平台抽象（Backstage/Kargo）
  用平台层的"环境模板"注册，自服务创建

共同点：环境是可重建、可销毁、可版本化的——不是"手点出来的"

# values-preview.yaml 按 PR 注入唯一标识
env:
  name: pr-1234
  imageTag: pr-1234-sha-abc123
  ingressHost: pr-1234.shop.plumephp.dev
  replicaCount: 1

# PR 触发时渲染并部署一套唯一环境
helm template app ./charts/app \
  --set env.name=pr-$PR_NUMBER \
  --set imageTag=$SHA \
  --set ingressHost=pr-$PR_NUMBER.shop.plumephp.dev \
  | kubectl apply -f -

per-PR 隔离的三种粒度：
  1. 独立 Namespace（推荐）
     每个 PR 一个 namespace → 资源/网络/权限天然隔离
  2. 独立 Deployment（共享 ns）
     省资源但依赖/服务名冲突，慎用
  3. 独立集群（最重）
     很少用，除非强隔离/安全要求

生产建议：per-PR Namespace + 短命名（pr-1234）

# PR namespace 内的一组资源
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: pr-1234
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: api
          image: registry/app:pr-1234-sha-abc123
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: pr-1234
# Ingress: pr-1234.shop.plumephp.dev → api service

统一入口：Ingress 按子域名分发
  pr-1234.shop.plumephp.dev → pr-1234 namespace
  *.<app>.plumephp.dev → 自动路由（通配证书 + 路径匹配）

预览环境的数据策略：
  - 方案 A：空库 + 迁移 + 种子脚本（轻量、可控）
  - 方案 B：从生产快照脱敏克隆（真实、但重、有合规风险）
  - 方案 C：只建"关键表" + 少量真实子集（平衡）

选择：
  - 后端逻辑依赖数据 → 至少方案 C
  - 敏感数据 → 必须脱敏（姓名/手机号/邮箱替换）
  - 巨大生产库 → 不直接克隆，用采样

# PR 环境启动流程（CI job）
- name: Setup preview db
  run: |
    kubectl apply -f pr-db.yaml          # 起一个临时 Postgres
    # 跑迁移 + 种子
    flyway migrate -url=$PR_DB_URL
    ./scripts/seed-demo-data.sh $PR_DB_URL

关键：环境每次是"新空库 + 自动迁移 + 种子"
  → 可重复、可销毁、不污染生产
  永远不要在预览环境上手动改数据（下次重建就没了）

拉起：PR opened → 触发 CI → 建 namespace + 部署 + Ingress + 数据
验证：冒烟/E2E/人工访问 URL → 报告状态（绿/红）
保持：PR 打开期间环境持续存在（可调试）
回收：PR 合并/关闭 → 自动删 namespace + PVC + 释放资源

生命周期状态机：
  creating → ready → testing → failed → (merged) → destroyed

必须防"僵尸环境"（PR 关闭了环境还在跑、烧钱）：
  - TTL：环境带上过期标签，超时自动删除
  - 巡检：定时扫描 namespace，匹配到已关闭 PR → 回收
  - 显式：CI 的 cleanup job 在 PR 关闭时跑

回收要"完整"：namespace 整体删除 + PVC + 外部依赖（DB/队列）一并释放

# 用一个清理 job 在 PR 关闭/合并时跑
kubectl delete namespace pr-$PR_NUMBER --ignore-not-found
# 或：TTL 定时器扫描带 label 的旧环境
kubectl get ns -l created-by=preview,ttl-expired=true -o name | xargs kubectl delete

每个 PR 一套环境 → 并发 N 个 PR = N 套环境
  - 每套都是"小而全"：DB+缓存+服务+入口
  - 高峰期几十套环境并行，成本可能超过一个 staging

控制手段：
  - 精简资源：replica=1、requests 调低、小镜像
  - 空闲自动缩：无访问几分钟 → scale 到 0（保留 PVC）
  - 数据最小化：不克隆生产全量
  - 严格回收：TTL + 巡检 + 关闭即删
  - 成本归属：按 PR 归属到团队/成本中心

# KEDA/自研：预览环境无人访问自动缩 0
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: preview-idle
  namespace: pr-1234
spec:
  scaleTargetRef: { name: api }
  minReplicaCount: 0
  maxReplicaCount: 1
  triggers:
    - type: cron
      metadata:
        # 用 cron 触发器实现"无访问缩 0"（配合探活）

简化：预浏览量低的 PR，可以在"超过 X 天无访问"后销毁整套
  记录访问日志，看 7 天无访问 → 提醒/回收

预览环境不只是"让人看"，更该跑自动化验证：
  - 冒烟：Healthcheck 通过（服务起来）
  - E2E：在 PR URL 上跑关键路径
  - API 契约：对预览环境跑 Pact 验证
  - 视觉回归：截图对比
  结果回写 PR 状态（comment + 门禁）

有了这些，合并前就有一份"这个 PR 真实可跑"的证据

策略：把"预览环境验证通过"设为合并前置条件（对核心服务）
  分三级：
  - 基础：构建+单元测试（合并必过）
  - 推荐：预览冒烟通过（核心变更要求）
  - 高级：E2E/契约通过（高危模块）

注意：预览环境验证是"增强"而非"替代"单元测试
  别让 CI 时间全部压到预览套件上（会变慢）

Kargo（Argo 生态）：
  把"环境晋升"（preview → staging → prod）自动化
  用 Freight（版本集：镜像+manifest+配置）驱动
  环境的 promote / verify / rollback 都成为"可声明、可审计"的流程

与预览环境的结合：
  PR → 预览环境（最新代码）→ 验证 → 晋升到 staging
  Kargo 负责"版本跟踪 + 自动晋升策略"

# Kargo Freight 表示一套可发布版本
apiVersion: kargo.akuity.io/v1alpha1
kind: Freight
metadata: { name: pr-1234-freight }
# 包含：应用镜像、manifests、配置的版本组合

好处：
  - 环境晋升有"审计轨迹"（谁、何时、哪版本）
  - 与 GitOps 统一（一个 Git 源驱动全部环境）
  - 预览环境的"验证通过"可作为晋升 gate

□ 环境定义进 Git（Helm/Kustomize/声明式）
□ per-PR Namespace 隔离 + 子域名统一入口
□ 数据库用"空库+迁移+种子"，避免克隆生产
□ 生命周期自动化：拉起/验证/回收全 CI 驱动
□ TTL + 巡检兜底，防僵尸环境
□ 资源精简 + 空闲自动缩 + 严格回收控成本
□ 冒烟/E2E 在预览环境跑，结果回写 PR 门禁
□ Kargo/环境编排管理晋升与审计
□ 成本归属与监控

预览环境的价值 = "合并前，你的改动已经在真实环境里被亲手验过"。