Tilt：资源图、Live Update 与可发布边界
Tilt 解决的不是“怎么少写一条 docker build”，而是多服务项目里谁依赖谁、一次文件变化该触发什么动作、失败停在哪一层，以及开发者如何看见整个反馈过程。它的核心资产是 Tiltfile：一段可编程配置把本地任务、镜像和 Kubernetes 对象组织成资源图。用得好，保存代码到看到结果只需几秒；用得差，它会把隐含脚本、集群权限和本地缓存叠成另一套难以解释的发布系统。
先建立最小资源图
在隔离开发集群中准备一个应用镜像和 Deployment。Tiltfile 明确镜像构建、清单来源、端口和上下文护栏：
allow_k8s_contexts('kind-inner-loop')
docker_build('example.local/orders', '.')
k8s_yaml('k8s/deployment.yaml')
k8s_resource('orders', port_forwards='8080:8080')allow_k8s_contexts 是非常重要的失败护栏。项目如果只允许本地 kind context，误连其他集群时应在启动阶段停止，而不是等第一次 apply 后才暴露目标错误。它仍不能替代 kubeconfig 分权：能修改 Tiltfile 的人可能改变允许列表，服务端 RBAC 必须继续把身份限制在开发 namespace。
启动前保存三份事实：kubectl config current-context、目标 namespace 的 auth can-i、Tilt 实际版本。随后执行 tilt up，观察镜像资源、Kubernetes 资源和端口转发是否分别进入健康状态。页面能打开只是最终证据之一，还应看到 Deployment generation 收敛、Pod Ready，以及容器使用预期镜像。
Tiltfile 是程序，不是静态 YAML
Tiltfile 使用 Starlark 风格语法，可以读取项目文件、定义函数、调用扩展并启动本地命令。这个能力适合表达资源依赖，也带来供应链与本地执行风险。代码评审不能只看 Kubernetes YAML，还要检查 Tiltfile 是否访问环境变量、执行 shell、下载扩展或读取工作区之外的文件。
资源图应与业务边界一致。数据库迁移要在依赖它的服务之前完成，生成代码要在镜像构建之前完成，基础设施任务不应因每次源码保存重复执行。resource_deps 能表达启动依赖，但不能自动判断业务数据是否真的准备好；健康检查与幂等性仍由任务自身负责。
Live Update 快在哪里，也会在哪里失真
Tilt 的 Live Update 规范明确以初始完整构建为基线，再根据文件变化执行同步与命令。典型规则是先声明哪些文件变化必须回退到镜像重建，再同步可热更新目录，最后在容器里执行重启或依赖安装命令。
docker_build(
'example.local/orders',
'.',
live_update=[
fall_back_on(['package-lock.json', 'Dockerfile']),
sync('./src', '/app/src'),
run('npm run build', trigger=['src/']),
],
)顺序决定语义。依赖清单或 Dockerfile 变化必须触发完整构建，否则运行中容器会形成一个从未存在过的镜像状态；源码同步后再执行构建，才能保证进程读取新产物。应用不支持热加载时，还要明确进程如何重启。仅看到文件被复制，不足以证明新代码已运行。
Live Update 改的是运行中容器文件系统。Pod 被重建后，这些变化会消失，CI 也不会继承它们。因此每个团队都要定期验证“干净构建路径”：停止同步，删除 Pod，从源码重新构建镜像，确认结果与快速循环一致。快速路径只能优化反馈，不能成为唯一真实路径。
观察失败发生在哪一层
| Tilt 资源状态 | 首个证据 | 典型责任层 |
|---|---|---|
| 镜像构建失败 | build log、上下文与依赖 | Dockerfile、网络、制品源 |
| deploy 失败 | 渲染清单、API 拒绝 | schema、RBAC、准入 |
| Pod 未就绪 | conditions、Events、logs | 调度、镜像、配置、探针 |
| Live Update 失败 | sync 路径、run 退出码 | ignore 规则、权限、进程 |
| 端口不可达 | forward 状态、Service、监听端口 | RBAC、Pod 生命周期、应用 |
不要把所有红色状态归因于 Tilt。它只是把多个工具的结果汇集起来。保留原始构建退出码、API 错误和 Pod 事件，才能知道修复应落在项目配置、集群平台还是应用代码。
团队环境需要明确成本和权限
Tilt 会持续观察文件、构建镜像、访问 registry、watch 集群资源、读取日志并建立端口转发。共享开发集群要为每位开发者提供独立 namespace 或稳定命名空间隔离，限制配额和镜像仓库权限，并约定资源命名，避免两个人的循环覆盖同一 Deployment。
本地构建缓存能节省时间，也可能掩盖缺失依赖。CI 应使用独立、可重建的缓存策略；Tiltfile 中的本地命令不能默认拥有个人云凭证。团队提交的配置应能在一台干净开发机上解释所有外部依赖。
多服务项目先处理依赖，不要追求同时变绿
服务多了之后，最诱人的配置是让所有资源同时启动。数据库迁移、代码生成、消息主题和下游模拟服务如果存在前置关系，同时启动只会制造大量次生错误。资源依赖应表达“谁的成功是下一步的前提”，但不能用固定 sleep 冒充健康。迁移任务需要明确退出码，服务需要 readiness，业务依赖则需要最小探测。
不是所有资源都要在每位开发者电脑上默认启动。Tilt 可以把昂贵或少用的资源设为手动触发，让项目启动保持可控。团队应提供几个按任务组织的入口，例如 API 开发、消费者开发或全链路验证；入口之间共享同一资源定义，不复制三套逐渐漂移的 Tiltfile。
资源名要与业务对象一致，而不是沿用镜像仓库的长路径。Tilt UI 中出现失败时，开发者应能直接找到 owner 和日志来源。一个资源聚合多个不相关任务，虽然界面更短，却会让其中一个失败阻断所有反馈。
本地资源也属于反馈环
并非每个依赖都在 Kubernetes。前端开发服务器、代码生成器、代理和测试监听器可以作为本地资源进入同一资源图。这样它们的启动顺序、输出和失败状态可见，不需要再开多个无人知道生命周期的终端窗口。
本地命令的风险高于普通配置：它继承开发者文件权限、环境变量和网络访问。命令应使用仓库内受审查脚本，固定工具版本，敏感变量只传给真正需要的进程。长期运行进程还必须响应停止信号，否则 tilt down 后可能继续占用端口或写入文件。
性能优化必须基于时间分解
觉得循环慢时，先把时间拆成文件检测、构建上下文发送、镜像构建、推送或加载、API apply、调度拉取、探针等待和应用响应。不同阶段的优化完全不同。盲目加大缓存可能掩盖依赖，缩短探针又会增加抖动，扩大同步范围则可能传输更多文件。
团队可以记录一次干净构建和一次典型源码变化的基线。优化后比较的不只是秒数，还包括失败能否被正确检测、镜像身份能否追踪、Pod 重建后能否复现。只有速度提升而证据减少，通常是在透支后续排障时间。
升级 Tilt 与扩展时保持资源图不变量
Tilt 二进制、Tiltfile API 和扩展会演进。升级前保存版本、资源列表、一次完整构建结果和两类 Live Update 实验；升级后重跑，并检查弃用提示。扩展必须固定来源与版本，不能在启动时悄悄执行远端主分支的新代码。
回退能力包括旧二进制和兼容配置，但更重要的是项目仍可不用 Tilt 完成标准镜像构建与清单部署。这个旁路保证工具故障不会阻断基本开发和发布，也提醒团队 Tilt 是反馈编排层，不是制品权威源。
调试、测试和发布的边界
Tilt 可以聚合日志、端口转发和本地任务，也能触发测试。它适合开发反馈，不应自动被提升为生产发布控制面。开发路径允许文件同步，发布路径必须由不可变镜像和审核清单完成；开发者端口转发是临时入口，不替代 Service、Ingress 与网络策略验收。
一个可靠的验收实验包含两次变化。第一次改源码，证明 Live Update 生效并由应用输出确认版本变化；第二次改依赖文件，证明系统没有继续同步，而是回退到完整镜像构建。若两种变化都表现为“页面更新了”，却无法说清使用的镜像摘要和运行路径，反馈环仍不可审计。
停止之后还要确认现场收敛
tilt down 应清理由当前项目管理的 Kubernetes 资源，端口转发和文件观察也应停止。执行前先保存需要的失败证据，执行后检查 namespace 中残留的 Deployment、Job、Pod、Service 和临时卷。数据库、共享依赖或 Tiltfile 外创建的资源未必属于自动清理范围，不能用一次 down 推断环境已空。
项目迁移或弃用 Tilt 时，退出对象还包括 Tiltfile、扩展依赖、本地脚本、缓存目录、registry 镜像和开发集群授权。最好的 Tilt 项目不是功能最多，而是资源图一眼可读、快速路径与干净构建一致、错误停在正确层，并且开发者随时知道这一轮变化究竟改了什么。
一次完整交付应保存两组时间与结果。干净路径记录从空缓存构建到业务探针通过的阶段耗时、镜像摘要和资源版本；快速路径记录典型源码变化命中的同步规则、进程重载和响应版本。再故意修改依赖锁文件，证明它会跳出同步路径并重新构建。三组证据一起存在，团队才能判断优化是否真实、失效条件是否可靠，也能在换电脑或换集群后快速发现漂移。只有一个绿色 UI 截图，既不能说明用的是哪条路径，也不能证明其他人能够重建。
还应故意制造一次可恢复失败：让构建命令返回非零，确认依赖资源不会继续使用错误制品；恢复源码后，观察资源图能否从失败节点继续，而不是要求删除整个开发环境。这个实验能检验错误传播、日志保留和重试边界。若修复一个服务必须清空所有缓存、重建全部资源，资源图虽然可视，实际仍缺少可维护的隔离。
失败也必须能被解释和复现。