Linux 应用发布实践：版本号、目录结构、压缩包与回滚

一、发布不只是复制文件

很多程序本地能跑，但上线后容易出问题，原因通常不是代码本身，而是发布流程不规范。

一个可靠发布流程要解决：

• 发布哪个版本。
• 发布哪些文件。
• 配置放在哪里。
• 日志怎么看。
• 失败怎么回滚。
• 依赖库是否齐全。
• 启动和停止是否可控。

二、推荐目录结构

/opt/my_app/
├── releases/
│   ├── 1.0.0/
│   │   ├── bin/
│   │   ├── lib/
│   │   └── conf/
│   └── 1.1.0/
├── current -> /opt/my_app/releases/1.1.0
└── shared/
    ├── logs/
    └── data/

好处：

• 多版本共存。
• current 指向当前版本。
• 回滚只需要切换软链接。
• 日志和数据不跟随版本删除。

三、版本号

建议使用语义化版本：

MAJOR.MINOR.PATCH

例如：

1.2.3

含义：

• MAJOR：不兼容变更。
• MINOR：新增功能。
• PATCH：问题修复。

程序启动时建议打印版本：

my_app version=1.2.3 commit=abc123 build_time=2026-06-21

四、打包

构建目录：

package/
├── bin/
│   └── my_app
├── lib/
├── conf/
│   └── app.conf
└── scripts/
    ├── start.sh
    └── stop.sh

压缩：

tar -czf my_app-1.2.3-linux-arm64.tar.gz package/

生成校验：

sha256sum my_app-1.2.3-linux-arm64.tar.gz > my_app-1.2.3-linux-arm64.tar.gz.sha256

五、部署

上传：

scp my_app-1.2.3-linux-arm64.tar.gz user@host:/tmp/

解压：

mkdir -p /opt/my_app/releases/1.2.3
tar -xzf /tmp/my_app-1.2.3-linux-arm64.tar.gz -C /opt/my_app/releases/1.2.3 --strip-components=1

切换版本：

ln -sfn /opt/my_app/releases/1.2.3 /opt/my_app/current

重启：

systemctl restart my_app

六、回滚

假设上一个版本是 1.2.2：

ln -sfn /opt/my_app/releases/1.2.2 /opt/my_app/current
systemctl restart my_app

回滚的前提是：

• 老版本仍在。
• 配置兼容。
• 数据结构兼容。
• 数据迁移可逆或不影响老版本。

七、systemd 配合

service 中使用 current：

[Service]
WorkingDirectory=/opt/my_app/current
ExecStart=/opt/my_app/current/bin/my_app --config /opt/my_app/current/conf/app.conf
Restart=on-failure

这样切换软链接后重启服务即可使用新版本。

八、发布前检查

发布前建议检查：

• 构建是否通过。
• 测试是否通过。
• 包名是否包含版本号和架构。
• 动态库是否齐全。
• 配置模板是否更新。
• 启动脚本是否可执行。
• 是否有回滚版本。
• 发布说明是否写清楚变更。

九、发布后检查

systemctl status my_app
journalctl -u my_app -n 100
ss -lntp
ps aux | grep my_app

业务层也要检查：

• 接口是否正常。
• 数据是否正常。
• 日志是否有错误。
• CPU/内存是否异常。

十、总结

发布流程的目标是可重复、可观察、可回滚。不要把发布做成手工复制文件的黑盒操作。

一个简单但可靠的结构是：

releases + current symlink + systemd + logs/data shared

这套方式适合大多数 Linux 应用和嵌入式 Linux 应用。