引言
上周团队里用Mac的同事跟我吐槽：每次要更新服务端项目，得先手动git pull拉最新代码，再跑打包命令，然后把打包文件传到服务器，最后登录服务器执行部署脚本，整套流程走下来最少10分钟，中间还经常漏步骤、改错配置，出问题还得回滚。而负责Linux服务器的同事早就用上了一键部署脚本，只有Mac端还停留在"手动操作时代"。这次的任务就是给Mac端做一套适配的一键拉取、打包、升级脚本，把整套流程封装成一行命令就能跑。
一、先摸透原有部署逻辑，避免无效适配
一开始我以为只要把原有Linux端的脚本改改路径、适配下Mac的shell环境就行，但看了几遍现有脚本之后发现完全不是这么回事：原有服务端部署脚本支持--dry-run参数，作用是仅跳过远程服务器上的部署步骤，本地的代码拉取、打包流程依然会正常执行；同时脚本对git pull失败的情况做了兼容，如果本地有未提交的变更导致拉取失败，会直接跳过拉取步骤继续后续打包，不会直接中断。
我还特意验证了服务器端的部署脚本参数、后端构建工具的依赖要求，确认Mac端已经安装了paramiko库用于SSH连接，再测试了SSH到服务器的连通性，把所有前置依赖都摸清楚之后才开始动手写脚本，避免后面改来改去反而破坏了原有流程的兼容性。
二、Mac适配过程中的两个核心踩坑点
整个适配过程踩了两个最典型的坑，差点让脚本没法用：
第一个是git拉取的异常场景。第一次测试脚本的时候，git pull直接报错，提示本地有未提交的变更，我当时以为是脚本逻辑写错了，后来翻了原有脚本的逻辑才发现，原有脚本本来就是允许git pull失败的，只是会跳过拉取步骤用本地代码继续打包------这次报错完全是因为我测试用的本地仓库之前改过测试文件没提交，属于预期内的异常，根本不是脚本的问题。
第二个是dry-run模式的逻辑误解。一开始我以为--dry-run是全流程只模拟不执行，结果测试的时候发现加了dry-run之后，本地拉取和打包还是正常跑了，只有远程部署被跳过。后来才搞清楚原有脚本的设计是dry-run只针对远程操作，方便开发者在本地验证打包逻辑是否正常，不需要真的往服务器上部署。如果我把这个逻辑改掉，反而会让原来用惯了Linux端脚本的同事不适应。
三、最终落地的脚本能力
摸透逻辑、踩完坑之后，最终的脚本实现了三个核心能力：
- 前置自动校验：运行脚本之前会自动检查Mac上的git、打包工具是否安装，paramiko依赖是否正常，SSH到服务器的连通性是否正常，有任何问题直接提示，不会跑到一半才报错；
- 全流程封装：从git拉取最新代码、执行本地打包，到用paramiko把打包文件传到服务器、调用服务器端的部署脚本执行升级，整套流程不需要任何手动操作；
- 兼容原有逻辑：完全复用原有脚本的异常处理、dry-run模式逻辑，Mac端和Linux端的脚本行为完全一致，不需要重新学习使用方法。
最后我还给Python脚本包了一层shell wrapper，核心逻辑只有几行透传参数的代码，同事只需要在项目目录下敲一行./deploy.sh或者加--dry-run参数就能跑，连python路径都不用记。
结尾
这次适配最大的收获是：跨端适配现有工具链的时候，永远先摸透原有逻辑再动手，不要上来就按自己的理解改。很多看起来"不合理"的逻辑，其实是之前踩过坑留下来的兼容性设计，随便改很容易出问题。另外跨端脚本一定要把前置校验做足，依赖、连通性、环境差异提前检查，比跑起来再报错排查效率高得多。现在这套脚本已经在团队里用了两个月，Mac端的部署时间从原来的10分钟降到了1分钟，再也没出现过漏步骤、改错配置的问题。