服务部署器

要解决什么问题

在 map-spec 联调阶段，你往往需要在同一台物理机上同时跑两套 async 类型的 navi-guide 服务：一套对应当前工作目录里的目标分支（可能还没 push），另一套对应基线分支，用于对比行为与回归。手工 clone、选端口、改配置、起进程，步骤多且容易把「传入端口」和「实际监听端口」搞混。

技能如何工作

Service Deployer 把流程收成固定管线：自动读取 target_branch（当前分支）、推导 baseline_branch，在本地探测可用端口后调用 testing/service-deployer/deploy_dual.sh 完成并行构建与启动。

• 目标服务：不拉仓库，直接在当前工作目录执行 build.sh + ngbuild.sh release。
• 基线服务：将基线分支 clone 到 ${home}/navi-guide（默认 home 为 /home/xiaoju/map-spec-deploy），在独立目录构建。
• 两个进程名均为 navi-guide-server，靠目录路径区分；失败会清理残留并返回 TARGET_DEPLOY_FAILED / BASELINE_DEPLOY_FAILED。

部署前还可选查 LLM-Wiki，参考历史端口规范、data_mode 与常见故障处理。脚本若发现端口被占，会在入口用 find_free_port 递增重试；技能会解析标准输出里的实际端口，结合本机 IP 写回配置，避免 config 仍写着未使用的传入端口。最后生成 deploy_report.md。

数据模式（data_mode，默认 single）：

• single：enable_road_data_manager = 0，走远程数据管理 10.74.92.51:9012。
• dual：本地灵犀 mock（testing/service-deployer/mock_data_manager.py），需先起 mock 再起服务；切稳定版时只需重启 mock，服务可不重启。

适用边界与注意点

• 服务类型固定为 async，feature 为必填参数；dual 依赖本地灵犀脚本与双版本数据，不适合无 mock 的环境。
• 目标分支代码以当前目录为准，技能不会替你 git clone / git reset 目标侧仓库。
• 基线路径与 home 需与团队部署约定一致，否则基线目录可能与现有安装冲突。