上传 iPA 这件事，我待过的团队大概分成两种。一种是把包拖进网页，看到进度条走完就关掉页面；另一种是把这一步塞进流水线，构建完自动往下走。
前者省事，后者省心。但真要接之前，有四件事得先定下来。不然自动得越快，错得越整齐。
上周四晚上八点四十，办公室只剩两个人。同事阿哲在群里发了一句：「构建版本还是空的，是不是没传上去？」我盯着 App Store Connect 那个一直在转的页面，心里发虚。包半小时前就传了，可我们从来没定过谁传、传哪一版、传完谁去核对。
那天晚上我们把四件事重新捋了一遍，值得写下来。
第一件，凭据归谁
上传要用的是 App Store Connect 的账号凭证。很多人第一反应是拿登录密码去填，其实苹果给的是另一把钥匙，叫 App 专用密码，专门给上传工具用，跟登录密码分开放。这一步不难，难的是后面那句：这个密码归谁管？
我们最早的做法是三个人各自记一份，谁发版谁填。结果有一次，一个同事换了手机，双重认证重新绑，专用密码失效，包传了一半断在那里，他还以为是网络问题，反复点重传。
后来改成专用一份，只放在流水线的密钥里。谁能看、多久换一次、换了之后通知谁，写在一张纸上。听起来麻烦，其实就十分钟的事。
这里有个坑，看起来方便，其实最危险：把密码直接写进构建脚本。脚本一提交，仓库里就有了；日志一开，控制台里也有了。上传走的是加密传输，平台那边也会按流程处理上传信息，但这些都管不住你自己贴出去的那一行字。
第二件，版本号和构建号
这两个东西很容易混。版本号是用户看到的那个，一点几、二点几；构建号是苹果用来区分同一版本下第几次上传的，藏在后面。
规则只有一句：同一个版本号里，构建号只能往上走。加了代码不加构建号，传十次，构建列表里还是那一个旧包。我们就这么干过，改完一个按钮，连传三遍，界面一点变化都没有，最后发现三次用的是同一个构建号。
现在我更愿意让流水线自己算：构建号用日期加当天序号，或者干脆自增，谁都不用记。人一多，记性最不可靠。
还有一点要提前知道：上传成功不等于构建处理完。包进去了，App Store Connect 里会显示处理中，过一阵才变成可用。这段时间里别急着点提交，也别以为丢了。
第三件，产物从哪来
流水线要上传的是 .ipa，这个包得先有人打出来。我的习惯是把产物目录固定下来，文件名带上版本号和构建号，上传前在本地先验一遍签名。验签这一步，十一月九号那篇写签名不一致的文章里提过，道理一样：包不对，传得再快也是白费。
Windows 和 Linux 上也能出包，跨平台框架现在都支持，不用为了传个包专门去借一台 Mac。上传工具本身支持分片和断点续传，网差的时候不用从头再来，大包尤其明显。
另外留个台账：谁传的、传的哪个包、几点传完的。真出事的时候，这几行字比任何解释都管用，也能省掉互相猜的那半天。
第四件，失败了怎么退，谁点提交
先说个让人安心的：上传失败不会动到线上版本。线上那个版本还在，用户该下的还能下。重传一个新的构建号就行，不用回滚，也不用半夜爬起来改服务器。
真正容易搞混的是另一头：上传成功不等于上线。包传进去了，提交审核这一步仍然是人工决定的。什么时候提、提哪个构建、审核备注写什么，得有人负责。
我见过最安静的翻车，是有人以为接了接口就等于自动发布，脚本跑通就下班了。第二天早上打开后台，发现提上去的是测试包。自动化能替你搬东西，搬什么、什么时候搬，还是得你说。
我们现在定得很死：流水线只负责把包传到处理完成，提交审核之前在群里说一声，谁点谁留个名。
四件事定完，发版日就不太慌了。上传这一步，能自动就早点自动，省下来的是每次十几分钟的等待和无数次「传了没」的确认。
但要说清楚，自动化的是搬运，不是决定。
手上正好只有一台 Windows、又不想为了传个包去借电脑的，可以把 .ipa 直接拖进 https://www.chuxueyun.com/pages/ipaupload ，传完在 App Store Connect 里看构建状态，剩下的照上面四件事走。