Merge pull request #2433 from pikasTech/docs/devlevel-l0-unit-tests
docs: 将微服务内部单元测试归入 L0
This commit is contained in:
Lyon
@@ -18,6 +18,7 @@ HWLAB G14 和 AgentRun CI/CD 的受控入口。任何 PR 监控、Tekton/Argo、
|
||||
- 本 skill 负责这两种方式的自动交付、运行面操作和事故处理；
|
||||
- L0 Function 与 L1 Native 不使用 CI/CD。
|
||||
- 能在 L0/L1 复现和修复的问题，不用反复 L2/L3 rollout 代替快速小回环；修复后再通过正常自动链回归对应集群方式。
|
||||
- L2 可由代理按任务需要自行判断；L3 的每一次生产操作都必须取得用户当次明确授权。
|
||||
|
||||
## 高频入口
|
||||
|
||||
|
||||
@@ -3,8 +3,8 @@ name: unidesk-devlevel
|
||||
description: >-
|
||||
UniDesk 四种开发与部署方式，定义 L0 Function、L1 Native、L2 Development
|
||||
和 L3 Production 的运行形态。用户提到 devlevel、开发等级、多级调试、
|
||||
native-first、CLI 直调函数、native 前后端、开发集群、生产集群开发方式，
|
||||
或要求问题优先低等级小回环再逐级回归时使用。
|
||||
native-first、CLI 直调函数、微服务内部单元测试、native 前后端、开发集群、
|
||||
生产集群开发方式，或要求问题优先低等级小回环再逐级回归时使用。
|
||||
---
|
||||
|
||||
# UniDesk 开发等级
|
||||
@@ -15,7 +15,7 @@ description: >-
|
||||
|
||||
| 等级 | 名称 | 调用路径 |
|
||||
| --- | --- | --- |
|
||||
| L0 | Function | `CLI -> native function` |
|
||||
| L0 | Function | `CLI -> native function`；单个微服务内部单元测试 |
|
||||
| L1 | Native | `CLI -> native API -> native Worker`；`web-probe -> native Web` |
|
||||
| L2 | Development | `CLI -> dev K8s API -> dev Worker`；`web-probe -> dev Web` |
|
||||
| L3 | Production | `CLI -> prod K8s API -> prod Worker`；`web-probe -> prod Web` |
|
||||
@@ -29,8 +29,10 @@ description: >-
|
||||
|
||||
- 不启动 API、Worker、Temporal、Web 或 Kubernetes workload。
|
||||
- 用项目 CLI 直接调用 native function、dispatcher、repository 或本地执行器。
|
||||
- 适合函数逻辑、配置解析、数据转换、领域服务和本地文件操作的快速开发。
|
||||
- 单个微服务内部、不启动服务进程且不跨服务通信的单元测试和组件测试属于 L0。
|
||||
- 适合函数逻辑、配置解析、数据转换、领域服务、微服务内部单元和本地文件操作的快速开发。
|
||||
- 只加载当前功能需要的本地依赖。
|
||||
- 测试一旦跨越 API、Worker、网络、进程或前后端边界，就使用 L1。
|
||||
|
||||
## L1 Native
|
||||
|
||||
@@ -44,6 +46,7 @@ description: >-
|
||||
## L2 Development
|
||||
|
||||
- 通过项目正常 CI/CD 把目标版本滚动到开发集群。
|
||||
- 代理可以根据功能和问题是否需要开发集群真实运行面，自行选择并执行 L2。
|
||||
- CLI 显式使用开发集群 `--over-api`，访问 dev K8s API 和 Worker。
|
||||
- Web 使用 `$unidesk-webdev` 与 owning YAML 选择的 development semantic origin。
|
||||
- 适合集群配置、容器运行时、共享依赖、开发域名和多人联调。
|
||||
@@ -56,21 +59,24 @@ description: >-
|
||||
- Web 使用 `$unidesk-webdev` 与 owning YAML 选择的 production semantic origin。
|
||||
- 适合生产发布、生产环境问题复现和生产入口检查。
|
||||
- 生产 branch、tag、target、namespace 和入口只从项目 owning YAML 与领域 skill 读取。
|
||||
- 生产写入仍需用户明确要求；选择 L3 不改变现有生产权限和安全边界。
|
||||
- 每一次执行 L3 都必须获得用户对本次生产操作的明确授权。
|
||||
- 不得沿用历史授权、其他任务授权、泛化的生产权限或“项目已经部署到生产”的事实。
|
||||
- 未取得本次明确授权时，只能说明需要 L3 并等待用户决定，不能执行生产写入。
|
||||
|
||||
## 选择方式
|
||||
|
||||
- 修改纯函数、解析器或领域逻辑时优先使用 L0。
|
||||
- 需要 HTTP、Worker、Workflow 或前端联调时使用 L1。
|
||||
- 需要开发集群真实容器、网络、SecretRef 或共享依赖时使用 L2。
|
||||
- 用户明确要求生产部署或生产问题只能在生产环境复现时使用 L3。
|
||||
- L2 可由代理根据任务实际需要自行判断和执行。
|
||||
- L3 只有在用户对本次生产操作明确授权后才能执行。
|
||||
- 调试 L2/L3 问题时，可以随时回到 L0/L1 做更快的局部实验。
|
||||
- 不因为项目已经部署到 L2/L3 而跳过日常 L0/L1 开发。
|
||||
|
||||
## 问题处理方式
|
||||
|
||||
- 遇到问题时，先选择能够复现根因的最低等级，建立最快的小回环。
|
||||
- 纯函数、解析和领域逻辑问题优先降到 L0。
|
||||
- 纯函数、解析、领域逻辑和单个微服务内部单元问题优先降到 L0。
|
||||
- API、Worker、Workflow、前后端联调问题优先降到 L1。
|
||||
- 只有依赖开发集群容器、网络、SecretRef 或共享服务时才留在 L2。
|
||||
- 只有生产环境特有的数据、流量、配置或外部依赖问题才留在 L3。
|
||||
@@ -79,6 +85,7 @@ description: >-
|
||||
- L0 修复的 L3 问题，依次回归 L0、L1、L2、L3；
|
||||
- L1 修复的 L2 问题，依次回归 L1、L2；
|
||||
- 回归只覆盖受影响路径和必要依赖。
|
||||
- 回归需要进入 L3 时必须停下并取得用户对本次生产操作的明确授权。
|
||||
- 这个顺序只用于问题处理，不改变四种开发方式可以自由选择和反复使用的定义。
|
||||
|
||||
## 项目适配
|
||||
|
||||
@@ -127,7 +127,7 @@ trans NC01:k3s kubectl -n temporal get service temporal-frontend \
|
||||
## Temporal 应用的 Native-first 闭环
|
||||
|
||||
- 使用 `$unidesk-devlevel` 表达应用当前采用的开发方式：
|
||||
- dispatcher/function 属于 L0；
|
||||
- dispatcher/function 和单个微服务内部单元测试属于 L0；
|
||||
- native API、Worker 和 Web 属于 L1；
|
||||
- 开发集群 API/Worker/Web 属于 L2；
|
||||
- 生产集群 API/Worker/Web 属于 L3；
|
||||
|
||||
Reference in New Issue
Block a user