code-push私有部署

当时在做 Cordova 热更新时，官方 code-push 服务在国外，国内网络环境下更新体验并不稳定；另外微软又没有开源服务端代码，所以最后还是决定自己搭一套私服。

后来在 GitHub 上找到了一个比较成熟的方案：

https://github.com/lisong/code-push-server/

我一开始也试过在 Windows 内网环境里折腾，能跑起来，但是过程很别扭：不少命令不兼容，还得捣鼓 ngrok 做穿透。最后还是直接上 Linux 云服务器更省心。

安装过程

1. 安装新版 Node

很多 Linux 发行版自带的 Node 版本都比较老，我当时是直接去官网下载对应的 Linux 二进制包，示例版本是 v6.11.3：

wget https://nodejs.org/dist/v6.11.3/node-v6.11.3-linux-x64.tar.xz

解压命令：

xz -d node-v6.11.3-linux-x64.tar.xz
tar -xvf node-v6.11.3-linux-x64.tar

然后把 Node 的目录加入环境变量：

echo $PATH
vim ~/.bashrc

# 在文件末尾加上
export PATH=/usr/local/node/bin:$PATH

# 刷新环境变量
source ~/.bashrc

2. 按照 README 安装 code-push-server

npm install code-push-server -g
code-push-server-db init --dbhost localhost --dbuser root --dbpassword ****** --dbport 33308

上面第二条命令是初始化 MySQL 数据库，数据库连通性最好先确认好，不然后面排查问题会比较烦。

3. 配置 config.js

vim config/config.js

这里至少要关注下面几项：

• 数据库连接参数。
• common.storageType，默认是 local，也支持七牛云、Amazon S3、阿里云 OSS。
• 本地存储目录和下载地址，目录需要手动创建。
• common.dataDir 看起来是给增量更新准备的，我当时查下来是 Cordova 还不支持，React Native 才会用到。

如果你用的是本地存储，目录权限不对的话，上传包时很容易报错。我当时为了先跑通，直接粗暴地给了目录权限：

sudo chmod 777 codepushworkspace

Cordova 插件配置

这里只说 Cordova，React Native 相关的我当时没没用到(什么时候我玩RN了，再来补充)。

插件地址：

https://github.com/Microsoft/cordova-plugin-code-push

官方示例只需要配置 deployment key：

<platform name="android">
    <preference name="CodePushDeploymentKey" value="YOUR-ANDROID-DEPLOYMENT-KEY" />
</platform>
<platform name="ios">
    <preference name="CodePushDeploymentKey" value="YOUR-IOS-DEPLOYMENT-KEY" />
</platform>

如果使用自建服务，还需要额外加上 CodePushServerUrl。下面我把真实地址和 key 都换成了占位符，实际使用时替换成你自己的值：

<platform name="android">
    <preference name="CodePushDeploymentKey" value="YOUR-ANDROID-DEPLOYMENT-KEY" />
    <preference name="CodePushServerUrl" value="http://your-server-ip:9000/" />
</platform>
<platform name="ios">
    <preference name="CodePushDeploymentKey" value="YOUR-IOS-DEPLOYMENT-KEY" />
    <preference name="CodePushServerUrl" value="http://your-server-ip:9000/" />
</platform>

命令行发布

自建服务下，大部分命令和官方 code-push CLI 是一致的，但有两个地方要特别注意。

1. 登录地址

# 默认会登录微软官方服务
code-push login

# 自建服务要显式指定地址
code-push login http://your-server-ip:port

2. 创建应用

正常情况下：

code-push app add ioetest

但我当时在 code-push-server 上踩到的坑是：应用名最好直接带上平台信息，命令里也把平台和 cordova 一起带上。这样后面管理 deployment key 和发布版本都会更清楚。

code-push app add demo-android android cordova
code-push app add demo-ios ios cordova

踩坑记录

1. 默认账号和 Web 管理台

安装完成后，默认只有一个账号：

admin / 123456

这个密码最好第一时间改掉。

如果想新增用户或者改用户信息，可以用 Web 版本操作。不过我当时没继续装完整的 Web 管理台，一方面用处没那么大，另一方面它确实有点坑：后台其实已经返回了更新包信息，但页面不一定能正常显示。

另外，当时 Web 端还碰到过跨域问题，需要改服务端 app.js，把 app.all 那里的环境判断注释掉，才能正常使用。所以我最后的感受是：Web 管理台拿来管理用户信息还行，但别指望它特别省心。

改密码也可以直接走命令行：

curl -X PATCH \
  -H "Authorization: Bearer mytoken" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{"oldPassword":"123456","newPassword":"654321"}' \
  http://127.0.0.1:3000/users/password

2. 端口、pm2 和配置文件

这里有两个端口概念容易混：

• 服务默认监听的端口是 3000，在 bin/www 里可以改。
• 实际对外暴露给客户端的地址不一定也是 3000。如果你前面还有 nginx 或其他转发，文章里的 9000 只是对外访问示例。

我当时是用 pm2 来管理进程，配置文件在 docs/process.json，启动命令：

pm2 start process.json

里面有个配置我一开始没看懂：

"instances": "max"

它的意思大概就是按照 CPU 核心数启动多个实例。

另外，env 里的 config 指向的是 config/config.js。这里我建议直接写绝对路径，后面排查问题会轻松很多。为了在根目录下快速操作，我还建了一个软链接：

ln -s /etc/node/lib/node_modules/code-push-server/docs/process.json /process.json

还有一个现象顺手记一下：release 的时候有时会报“无法解析 response”，但实际上版本已经发布成功了，当时看起来更像是 code-push-server 自己的兼容问题。

pm2 常用命令也一起记一下：

pm2 stop servername
pm2 delete servername
pm2 log servername

如果只是想模拟一次更新检查，我当时用的是这种请求格式：

http://your-server-ip:port/updateCheck?gldeploymentKey=YOUR_DEPLOYMENT_KEY&appVersion=3.6.26

3. code-push-cli 的登录缓存问题

有一次我把之前搭的私服停掉了，结果 logout 死活退不干净，删 access-key 也没用，我一度以为只能把 CLI 卸载重装。

后来去 lisong/code-push-server 提了个 issue，才知道问题不在安装目录，而是在用户目录下有个隐藏文件：

.code-push.config

这个文件会保存登录信息，把它删掉就好了。

4. 和 WKWebView 的冲突

后面又遇到过一个更隐蔽的问题，最后定位下来是和 WKWebView 插件冲突。

我当时卡了很久，后来翻自己之前提的 issue，发现已经有人给出解决方案了：在 code-push-server 根目录下的 app.js 里补上下面几个请求头，问题就能解决。

x-codepush-plugin-name
x-codepush-plugin-version
x-codepush-sdk-version

我当时为了先跑通，没有再去配 nginx 转发，而是直接把 env 的环境判断注释掉了。这个做法比较“应急”，更稳妥的方案还是走标准反向代理和环境配置。

小结

整个过程里，真正难的不是“安装”，而是那些文档里一笔带过的细节：CLI 登录信息存哪、Web 管理台为什么不好用、以及 WKWebView 这种很隐蔽的兼容问题。

如果只是想快速把私服跑起来，照 README 配一遍基本够用；但如果是要让团队长期用，建议一开始就把 Linux 部署、目录权限、pm2 管理和客户端配置这些细节一起捋顺，后面会省掉很多时间。