DevOpsCLICI/CD【免费下载链接】shipitUniversal automation and deployment tool ⛵️项目地址https://gitcode.com/gh_mirrors/sh/shipit点击查看免费下载本文基于 shipit 仓库中的 Windows 部署文档packages/shipit-deploy/docs/Windows.md面向需要在 Windows 环境下运行 shipit-deploy 自动化发布的开发者。读完本文你将掌握如何用 Scoop 安装 OpenSSH、rsync、pshazz 三件套如何正确配置 SSH 私钥路径key如何绕开 Windows 盘符与 rsync 路径约定之间的冲突rsyncFrom并理解每一步背后 shipit-deploy / ssh-pool 的源码实现使配置真正可复制、可验证。为什么 shipit-deploy 在 Windows 上需要特殊准备shipit-deploy 是 Shipit 的部署任务集合其deploy命令会按固定链条依次执行 6 个子任务注册入口见 deploy/index.jsdeploy:init → deploy:fetch → deploy:update → deploy:publish → deploy:clean → deploy:finish其中与 Windows 环境强相关的有两处deploy:fetch在本地 workspace 中执行git init/git fetch/git checkout等本地命令见 fetch.js。deploy:update调用shipit.remoteCopy把构建产物同步到远端服务器底层是本地 rsync ssh 命令见 update.js。也就是说即使目标服务器是 LinuxWindows 客户端本机也必须能跑通ssh、rsync以及脚本执行环境。这正是原文档开头强调 Requires Powershell 的原因shipit-cli 的任务脚本以 shell 脚本形式驱动而 rsync 在 Windows 上的行为又与 Linux 不同因此需要按下面的步骤单独准备环境。第一步用 Scoop 安装基础工具原文档要求通过 Scoop 安装依赖。在 PowerShell 中执行iex (new-object net.webclient).downloadstring(https://get.scoop.sh) set-executionpolicy unrestricted -s cu第二条命令调整当前用户的 PowerShell 执行策略这是 Scoop 安装脚本能正常落地的前提。接着安装三个核心程序scoop install openssh scoop install rsync scoop install pshazz三者的分工工具作用在 shipit 中的用途OpenSSH提供ssh.exe执行shipit.remote()的所有远端命令rsync提供rsync.exedeploy:update阶段把 workspace 增量同步到远端 release 目录pshazz让 PowerShell 能执行类 bash 的命令脚本使 shipit 任务链中的 shell 风格脚本在 PowerShell 环境可运行一个值得注意的底层细节ssh-pool 在发起远端拷贝前会先用which(rsync)探测本机是否支持 rsync见 rsync.js探测失败时会回退到 scp tar 的慢速方案Connection.js。因此务必确保rsync.exe在 PATH 中可被找到否则部署不会报错但会退化。第二步配置 SSH 私钥keyshipit-deploy 通过key配置项指定 SSH 私钥路径README Options 章节。原文档给出的 Windows 写法是key: c:/users/username/.ssh/id_rsa关键点Windows 风格绝对路径必须把反斜杠\替换为正斜杠/。这不是格式洁癖而是由命令拼接方式决定的——key最终会被直接拼进命令行作为 ssh 的-i参数// packages/ssh-pool/src/commands/ssh.js if (key) args [...args, -i, key]见 ssh.js。同一把 key 还会被复用为 rsync 的远端传输通道Connection.rsyncCopy会先用formatSshCommand({ key, ... })生成 ssh 子命令再通过--rsh参数交给 rsync见 Connection.js 与 rsync.js// rsyncCopy 中拼装出的命令形如 // rsync --archive --compress --rsh ssh -i key -o StrictHostKeyChecking... src dest这条拼接逻辑有对应的单元测试佐证例如 rsync.test.js 验证了remoteShell会以--rsh ssh形式出现在命令中。所以key路径写错、或写成含反斜杠的形式会导致 ssh 找不到私钥表现为授权失败或 rsync 反复弹出密码提示。第三步解决 workspace 盘符问题Windows 最大的坑原文档用大量篇幅记录了一个 Windows 特有的矛盾一方面shipit 会把当前盘符作为目录树的根来使用 workspace 路径另一方面rsync 要求源路径里显式带上盘符。原文档作者在项目位于D:盘时逐一尝试过三种workspace写法结果如下workspace 配置项目拷贝位置rsync 表现/workspace/d:\workspace失败rsync 找不到文件夹d:/workspace/d:\workspace失败rsync 找不到文件夹/d/workspace/d:\d\workspacersync 能正常从D:\workspace同步但项目被拷贝到了错误位置这个矛盾在源码里可以找到清晰解释项目拷贝侧deploy:fetch的setupWorkspace直接使用shipit.config.workspace作为 git 仓库初始化目录fetch.js。当 workspace 写成/d/workspace/这种盘符当目录的形式时Node 在d:盘上下文中解析它会落到d:\d\workspace于是出现项目被拷到d:\d\workspace的现象。rsync 同步侧deploy:update的remoteCopy用p.resolve(rsyncFrom, dirToCopy)计算本地源目录并在末尾强制补上/作为 rsync 源路径update.jsconst rsyncFrom shipit.config.rsyncFrom || shipit.workspace const uploadDirPath p.resolve(rsyncFrom, shipit.config.dirToCopy || ) // ... await shipit.remoteCopy(srcDirectory, shipit.releasePath, options)rsync 在 Windows 上把/d/workspace/这类Unix 风格 盘符的路径解释为D:\workspace却完全不认识D:\workspace或裸/workspace/。两侧的路径方言不一致就是文档中所有尝试失败或只成功一半的根源。官方支持的解法rsyncFrom配置项原文档记载作者最终选择了第 1 种写法/workspace/并通过一次源码修改在 PR 中追加了rsyncDrive配置项让 rsync 源路径自动带上盘符解决了 rsync 侧的问题。在当前上游代码中这一能力已经以rsyncFrom配置项的形式落地READMEWhen deploying from Windows, prepend the workspace path with the drive letter. For example/d/tmp/workspaceif your workspace is located ind:\tmp\workspace.也就是说当 workspace 位于d:\tmp\workspace时配置rsyncFrom: /d/tmp/workspaceremoteCopy就会用这个带盘符的 Unix 风格路径去跑 rsync而项目拷贝仍走workspace配置的语义。两者各司其职正好分别满足上面源码分析中的两条路径。相关提示如果启用了shallowClone: truesetupWorkspace会创建一个临时目录并忽略workspace配置fetch.js此时 rsync 源取自该临时目录通常位于系统盘如 C:盘符问题一般不会出现需要跨盘符的固定 workspace 场景才需要rsyncFrom。Windows 下的完整 shipitfile 示例综合原文档与 README 配置示例一个 Windows 环境可运行的配置骨架如下处替换为实际值module.exports shipit { require(shipit-deploy)(shipit) shipit.initConfig({ default: { workspace: /workspace, // shipit 拷贝项目用相对当前盘符解析 rsyncFrom: /d/workspace, // rsync 源路径显式带 D 盘盘符 deployTo: /var/myapp, // 远端部署目录POSIX 风格 repositoryUrl: https://github.com/username/repo.git, branch: master, ignores: [.git, node_modules], keepReleases: 2, key: c:/users/username/.ssh/id_rsa, shallowClone: false, // 使用固定 workspace 时需关闭 keepWorkspace: false, }, staging: { servers: deployyour-server, }, }) }配置会被extendShipit合并默认值并校验缺deployTo会直接抛错见 extendShipit.js。执行部署shipit staging deploy如需回滚使用shipit staging rollback。故障排查ssh 可执行文件冲突原文档 Troubleshooting 一节记录了一个高频问题Rsync 优先使用它自带的ssh.exe。如果安装了 gitbash或其他自带 ssh.exe 的程序要确保 PATH 中默认被使用的ssh.exe是 rsync 目录下的那一个。提示可以把 rsync 的安装目录放到 PATH 最前面来实现。结合源码可以解释为什么会这样如前所述rsync 的远端通道是通过--rsh参数注入的 ssh 命令rsync.jsrsync 子进程启动 ssh 时按PATH 搜索顺序解析可执行文件若 PATH 里 Git for Windows 的ssh.exe排在前面就会出现shipit 直连 ssh 正常、rsync 同步时却报 host key 异常/反复要密码之类的错位现象因为两个 ssh 客户端各自维护known_hosts与配置。解决办法就是文档给出的保证 rsync 自带的ssh.exe在 PATH 中优先级最高。小结Windows 部署检查清单PowerShell 已安装 Scoop并执行过set-executionpolicy unrestricted -s cuscoop install openssh、scoop install rsync、scoop install pshazz均完成where rsync能找到 rsync 目录下的rsync.exekey使用正斜杠的 Windows 绝对路径且对应私钥对部署服务器可用workspace与rsyncFrom分开配置前者决定项目拷贝位置后者以/d/...形式为 rsync 提供带盘符的源路径PATH 中 rsync 目录的ssh.exe优先于其他 ssh 客户端用shipit staging deploy走完整任务链验证关注deploy:fetch的 workspace 日志与deploy:update的 rsync 输出。以上步骤与配置项均可在仓库中交叉验证环境要求来自 Windows 部署文档配置语义来自 shipit-deploy README命令拼接行为来自 ssh-pool 命令构建器 及其测试用例。赞分享DevOpsCLICI/CD【免费下载链接】shipitUniversal automation and deployment tool ⛵️项目地址https://gitcode.com/gh_mirrors/sh/shipit点击查看免费下载相关推荐Shipit Windows 部署实战指南shipit-deploy 在 Windows 下的环境准备、key 与 workspace 盘符配置Shipit Windows 部署实战指南shipit deploy 在 Windows 下的环境准备、key 与 workspace 盘符配置 本文基于仓库DevOpsCLICI/CD解决Windows环境依赖噩梦Scoop容器化部署完全指南解决Windows环境依赖噩梦Scoop容器化部署完全指南 你是否还在为Windows开发环境的依赖冲突而头疼团队协作时在我电脑上能运行是否已成常态开发工具CLI新手必看7-Zip命令行完全上手教程10分钟掌握高效压缩技巧新手必看7 Zip命令行完全上手教程10分钟掌握高效压缩技巧 7 Zip是一款功能强大的开源压缩工具支持多种压缩格式通过命令行操作可以实现高效的文件压缩文档前端上一篇oh-my-hermes egress attempts 预写日志指南1 条记录如何防止 AI Agent 外部副作用失控下一篇终极窗口分辨率控制指南用SRWE轻松突破游戏窗口限制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考