企业官网建设流程全解析

• 开发工具
• CLI

devenv 将任务运行器（task runner）作为核心抽象后，进一步把所有进程统一暴露为名为devenv:processes:<name>的任务，从而在进程启动前后插入任意任务，解决了开发者长期诉求的启动顺序编排问题。读完本文你将掌握：如何在devenv up之前自动执行数据库迁移、在进程停止后执行清理脚本，以及进程任务化背后的任务依赖图、RunMode与进程管理器适配的完整实现原理。

背景：任务系统与进程的统一

devenv 本身提供了一套声明式任务系统（tasks），任务以 Nix 属性集定义，支持before/after依赖关系、状态检查、文件变更触发等能力。从 2025 年 7 月的这一版本开始，所有进程都被等价地视为任务：只要在devenv.nix中声明了processes.backend，devenv 就会自动生成一个名为devenv:processes:backend的任务（类型为process）。这一机制的直接收益是：进程与普通任务共享同一套依赖编排引擎，进程启动前/停止后都可以挂载其他任务。

该能力由模块 src/modules/processes.nix 与 src/modules/tasks.nix 共同实现。前者负责把每个进程转换为任务，后者负责定义任务的全部选项与依赖语义。

用法一：在进程启动前执行 setup 任务

最常见的需求是在后端服务启动前完成数据库迁移、生成配置或安装依赖。原文档给出的示例是：

{ processes.backend = { exec = "cargo run --release"; }; tasks."db:migrate" = { exec = "diesel migration run"; before = [ "devenv:processes:backend" ]; }; }

tasks."db:migrate".before表示“本任务必须先于devenv:processes:backend完成”。运行devenv up或单独启动该进程任务时，迁移会先执行，进程随后才被拉起。从依赖图的角度看，before声明了本任务是下游任务（进程任务）的前置依赖，进程任务会等待db:migrate成功退出后才启动。

用法二：在进程停止后执行 cleanup 任务

进程任务化也让“进程结束后做清理”变得声明式：

{ processes.app = { exec = "node server.js"; }; tasks."app:cleanup" = { exec = '' rm -f ./server.pid rm -rf ./tmp/* ''; after = [ "devenv:processes:app" ]; }; }

tasks."app:cleanup".after = [ "devenv:processes:app" ]表示 cleanup 任务等待进程任务结束后再执行，可用于删除 pid 文件、清理临时目录、通知外部系统等。需要说明的是，exec中的rm属于用户编写的任务命令本身（即项目清理逻辑），与仓库的只读约束无关，这是 devenv 用户项目中的正常配置写法。

深入：before/after的依赖语义与后缀

在 src/modules/tasks.nix 中，任务模块为before/after提供了精确的依赖语义。默认情况下：

• 任务（oneshot）之间：after = [ "task" ]等待前置任务成功退出（相当于@succeeded）；
• 进程（process）之间：after = [ "devenv:processes:x" ]等待进程就绪/健康（相当于@ready，仅进程可用）。

为了更精细地控制依赖行为，可以在任务名后追加四种后缀：

例如after = [ "pnpm:install@completed" ]允许本任务即使pnpm:install失败也继续运行；而after = [ "devenv:processes:postgres" ]则会等待 Postgres 进程就绪后再启动依赖方。此外任务还支持wantedBy（类似 systemd 的wantedBy，控制哪些任务会选中本任务）、status（检查命令是否应执行）、execIfModified（文件变更触发执行）等选项，这些与before/after可组合使用。

值得注意的是，processes.*.before与processes.*.after（见 src/modules/processes.nix）直接透传给对应进程任务，即进程既可以通过自己的before/after声明依赖，也可以被普通任务通过devenv:processes:<name>引用。start.enable默认true，若设为false则进程不会被devenv up自动启动，但仍会作为任务依赖被拉起，例如after = [ "devenv:processes:<name>@completed" ]。

实现原理：进程如何通过devenv-tasks运行

原文档明确指出，实现上process-compose 不再直接执行进程命令，而是通过devenv-tasks run --mode all devenv:processes:<name>来运行。这一机制在仓库源码中有完整印证。

在 src/modules/processes.nix 中，模块将每个进程转换为任务：

tasks = lib.mapAttrs' (name: process: { name = "devenv:processes:${name}"; value = { type = "process"; exec = process.exec; env = process.env; cwd = process.cwd; after = process.after; before = process.before; showOutput = true; process = { ... }; # ready/restart/listen/ports/watch 等透传 }; }) config.processes;

随后为每个启用的进程生成运行命令process.taskCommandsBase，其核心是一条devenv-tasks run --mode all --task-file ... devenv:processes:<name>调用；为了正确的信号处理，process.taskCommands再为它加上exec前缀（exec devenv-tasks run ...）。最终这些命令被写入 Procfile，由 process-compose 拉起。

--mode all的含义在 devenv-tasks/src/config.rs 中有明确定义：

pub enum RunMode { /// Run only the specified task without dependencies Single, /// Run the specified task and the tasks that run after it (downstream tasks) After, /// Run all dependency tasks first, then the specified task (upstream tasks) Before, #[default] /// Run the specified task with its upstream and downstream tasks All, }

可见--mode all会同时执行该任务的**上游（before）与下游（after）**任务，从而完整保住进程的预期生命周期：启动前先跑 setup 任务，停止后执行 cleanup 任务。

两种进程管理器的适配差异

• process-compose：在 src/modules/process-managers/process-compose.nix 中，非交互、已启用的进程统一使用包装命令config.process.taskCommands.${name}（即exec devenv-tasks run --mode all devenv:processes:<name>），并为其设置shutdown.signal = 15、timeout_seconds = grace + 5，给任务清理留出裕量；devenv:processes:前缀之外，还通过depends_on把before列表转换为 process-compose 的依赖条件。进程名称前缀常量定义于 devenv-tasks/src/types.rs（PROCESS_TASK_PREFIX = "devenv:processes:"）。
• native 进程管理器（devenv 2.0+ 默认）：src/modules/process-managers/native.nix 中devenv up直接从 Rust 调用任务运行器，将全部devenv:processes:<name>作为 roots 一次性devenv-tasks run --mode all提交，由同一个NativeProcessManager统一管理；process.manager.before/after在 native 下不再支持，改用任务依赖替代（见 src/modules/processes.nix 中的相关 assertion）。

源码级验证：依赖解析与测试

进程任务化不是简单的命令拼接，而是进入了真正的任务依赖图。在 devenv-tasks/src/tasks.rs 中，任务被建模为petgraph有向图，toposort与has_path_connecting用于拓扑排序与依赖连通性判断；进程任务与非进程任务通过after/before边连接，RunMode::All会从 roots 出发展开全部上游与下游任务。

仓库测试 devenv-tasks/src/tests/mod.rs 中的test_run_mode_all_includes_selected_dependents_prerequisites用例直接以devenv:processes:server为 root，验证了RunMode::All会调度被选中依赖方的全部前置任务（如web:build、browser:test），同时排除无关依赖方（unrelated:test），确保“不把共享前置任务的其他下游拉进来”。这正是进程任务化后before/after编排行为正确性的直接证据。

后续展望

原文档指出，进程依赖的进一步工作将顺带引入原生健康检查支持，届时不再需要为“等待服务就绪”编写轮询脚本，devenv:processes:<name>@ready语义将由内置探测（如 HTTP/exec/端口探测）直接支撑。目前进程任务已支持process.ready（exec/http/notify 三种就绪探测）与process.watch（文件变更自动重启）等能力，健康检查的原生化将让整个启动序列更加自洽。

总而言之，进程任务化让 devenv 的进程编排从“仅能启动进程”进化为“围绕进程构建完整生命周期”：迁移先行、进程就绪、清理善后，全部用同一套声明式任务语法表达，并可被任何普通任务通过devenv:processes:<name>精确引用。

• 开发工具
• CLI