docs: name distributed agile workflow
This commit is contained in:
@@ -44,9 +44,11 @@ Any manual repair that changes live credentials, env wiring, DNS/egress assumpti
|
||||
|
||||
If a manual repair is needed to unblock the platform, the durable fix must be committed and pushed, then redeployed or revalidated through the normal path. Do not preserve the repair only as hidden runtime state.
|
||||
|
||||
## Distributed Field Repair Flow
|
||||
## 分布式敏捷流程
|
||||
|
||||
Distributed development should support fast field learning without letting runtime edits become hidden deployment truth. The standard flow is:
|
||||
“分布式敏捷”是 UniDesk 对 distributed agile field repair 的固定流程名。后续 issue、PR、指挥记录或用户反馈提到“分布式敏捷”时,默认指下面这套流程:先在真实分布式运行面快速探测和实验补丁,形成可复现的证据与复盘 issue,再把有效修复收敛为 Git/PR/CI/CD 的持久化交付,最后从原始用户入口复测。它允许快速现场学习,但不允许运行面改动变成隐藏部署真相。
|
||||
|
||||
The standard flow is:
|
||||
|
||||
1. Probe the real runtime surface first. Use structured UniDesk passthrough, service health endpoints, trace/result polling, bounded logs, object metadata and user-entry requests to reproduce the symptom on the actual target environment. Prefer short single-step commands that return promptly and can be repeated.
|
||||
2. Apply an experimental runtime patch only when it is needed to prove a fix direction. The patch must be narrow, named, reversible and scoped to the affected deployment, pod, ConfigMap, env key, script mount or file. It must not include secrets, broad filesystem rewrites, unmanaged image builds, destructive resets or unrelated cleanup.
|
||||
|
||||
Reference in New Issue
Block a user