大数跨境

给 WorkMate 打包发货:一个 .exe 的安全之旅

给 WorkMate 打包发货:一个 .exe 的安全之旅 兆企供应链综合服务平台
2026-10-12
2

WORKMATE · 交付

给 WorkMate 打包发货:一个 .exe 的安全之旅

一条命令 · 八步流水线 · 四道防线

CHAPTER 26 · 交付篇

上一篇文章,我们讲了企业怎么把 WorkMate 装起来——管理端一条 Docker 命令,员工端一个 .exe 双击就装。很多读者看完后,心里可能还留着一个疑问:「员工端那个安装包,到底是怎么来的?」

这个问题问得好。因为对员工来说,装 WorkMate 确实简单到「双击、下一步、完成」;但对把 WorkMate 交付给企业的人来说,那个小小的 .exe 安装包,背后是一整套严谨的「打包与发布」流程。

这篇文章,就带你走到幕后,看看这个安装包是怎么被打出来、验干净、再安全地送到每个员工电脑上的。

CHAPTER 01

这个 .exe 里,到底装了什么

先说结论:WorkMate 的桌面端安装包,是一个「自包含」的完整软件包。什么叫自包含?就是它把运行所需的东西几乎全打包进去了,员工电脑上不用额外装一堆依赖。

桌面端本体 workmate-desktop.exe

员工每天打开、跟 AI 对话的那个界面程序。

本地服务 serve.exe

藏在后台,负责承载微信、企业微信、Windows 这些本地能力的调用。员工看不到它,但它一直在默默干活。

独立的 Python 运行时

WorkMate 的技能(Skills)是用 Python 写的,安装包里自带一份干净的 Python,不依赖员工电脑上装没装 Python。

独立的 Node 运行时

自带的 Node、npm、npx,员工电脑上没装 Node 也能跑。

一个 LibreOffice

用来把文档在 Word、Excel、PPT 之间转换,同样是打包进去的,员工不用另外装 Office。

发行配置 distribution.json

里面只存公开的 Admin 地址、环境标识这些非敏感信息,告诉桌面端「该去哪找管理端、该走哪个更新通道」。

看到这里你就明白了:员工端之所以能「双击就装、装完就用」,是因为这个安装包把该带的都带齐了。把复杂的准备动作,都消化在打包这个环节里,留给员工的只有「下一步」。


▲ 一个自包含安装包里装着的六样东西

CHAPTER 02

第一步,先把源码拿下来

打包的前提,是你手里得有一份 WorkMate 的源码。WorkMate 是开源的,源码就托管在 GitHub 上。

git clone https://github.com/richsupply/workmate
cd workmate

后面所有打包命令,都在项目根目录下执行

这里要提醒一句:打包用的源码,最好锁定在一个明确的版本上(比如切到某个 tag 或某个 commit),而不是随手拿最新的开发分支。因为打包讲究的是「可复现」——同一个源码,任何时候打出来的包都应该是可预期的。

源码到手、版本锁定,这才算真正具备了打包的前提。

CHAPTER 03

打包之前,先定三件事

有了源码,也不是上来就点按钮,还得先把三件关键的事定清楚。

01 版本号:严格用「主版本.次版本.修订号」三段式,比如 0.2.8。而且有一条硬规矩:新发布的版本,不能低于历史上已经发布过的最高版本。版本只能往前走,不能倒退——否则员工电脑上已经装了新版,又收到一个旧版更新,那就乱套了。

02 环境隔离:安装包分正式环境(production)和常规环境(normal),两者彻底分开——安装目录不同、更新通道不同、下载缓存也隔离。正式环境给真实业务用,常规环境给测试、演示用,绝不能串。

03 Admin 地址要显式指定:打包时必须明确告诉它「这个安装包将来连哪个管理端地址」,不再有默认值,必须由打包的人主动传进去。过渡期可以用 HTTP,等部署了 HTTPS 证书就强制 HTTPS——因为 HTTP 会明文传输登录令牌。

这三件事定下来,打包才有了明确的目标。

CHAPTER 04

一条命令,把安装包打出来

准备工作就绪后,真正的打包,其实是一条命令就能驱动的。这条命令背后是一套自动化「流水线」,它会依次干完这些事:

01 下载并校验 LibreOffice:从官方源下载固定版本,然后校验哈希值(SHA-256),确认文件没被篡改、没损坏,才允许使用。

02 生成版本资源:把版本号写进两个程序的 Windows 版本信息里,这样右键看属性能看到正确的版本号。

03 构建桌面端和服务:用打包工具把桌面端和 serve.exe 编译出来。

04 把运行时复制进去:把 LibreOffice、独立 Python、Node 这些按规定的目录结构放好。

05 写入发行配置:把环境标识、Admin 地址、更新开关写进 distribution.json。

06 安全扫描:这是最关键的一步——扫描并删除所有 .env 文件(就是那些存密码、密钥的配置文件),确保它们一个都不留。

07 编译安装包:用 Inno Setup 把上面所有东西压缩成一个 .exe 安装包,用最高压缩率,为的是让安装包尽量小、方便下载。

08 算哈希、出清单:算出安装包的大小和 SHA-256,生成一个同名的 JSON 清单文件,把环境、地址、版本、哈希都记下来。

你看,这一整套流程,打包的人只需要敲一条命令,剩下的全自动完成。这正是 WorkMate 「低成本、易上手」的体现——把复杂的构建过程,封装成一条命令。


▲ 一条命令背后的八步流水线

CHAPTER 05

安全,是打包的第一道红线

如果只能挑一个词来形容这个打包流程,我会选「安全」。因为一个安装包,是要装到成千上万员工电脑上的。如果它里面不小心带了一个密钥、一个密码、一条开发机的绝对路径,后果不堪设想。

DEFENSE 01

敏感文件绝不落包

.env 文件、数据库密码、OSS 凭证、登录令牌、开发机的绝对路径——打包时会专门扫描并删除,一个都不能进安装包。distribution.json 里也只允许存公开的 Admin 地址,不允许存任何令牌或凭证。

DEFENSE 02

哈希校验,防篡改

安装包打出来后会算一个 SHA-256 哈希值记录在清单里。员工下载安装时,客户端会再算一遍,跟清单对不上就认为文件损坏或被篡改,直接删除、拒绝安装。

DEFENSE 03

依赖固定版本、固定哈希

不只是安装包本身,连它依赖的 LibreOffice 也是固定版本、固定哈希的。不会因为上游悄悄更新了某个组件,就引入不可控的变化。

DEFENSE 04

技能不预置,登录后从管理端同步

安装包里不预装任何技能(Skills),员工登录后才从管理端统一同步、统一审核。员工不能随意下载技能、随意配置工具,杜绝外部工具恶意入侵的风险。

这四道防线叠在一起,回答的是同一个问题:怎么让企业敢把这个 .exe 装到员工电脑上。答案是——从源头保证它干净、可信、可控。


▲ 四道防线:从源头保证干净、可信、可控

CHAPTER 06

打出来还不够,得先自己验一遍

安装包打出来,不代表就能直接发布。正式发布前,还有一道「验收」关卡。

01 先验产物:确认安装包和清单文件都在,SHA-256 对得上,两个程序的版本号一致,目录里没有残留的 .env 文件,LibreOffice 路径正确,技能路径为空(因为技能要登录后同步)。

02 再做覆盖安装验收:拿一台已经装了旧版本的电脑跑一遍新安装包,确认原来的配置、技能、工作区、日志都还在;安装时弹出 Windows 的权限确认(UAC);装完能正常启动、设置页显示新版本。

03 还要在干净环境测文档解析:找一台没装过 Office 的干净 Windows 电脑,用带中文和空格的路径,同时解析一份 .doc、.xls、.ppt,确认都能正常转换,两个转换任务不会打架,测完没有残留进程。

这些验收看起来琐碎,但每一环都对应着员工真实会遇到的场景。只有这些都过了,才敢把包交出去。

CHAPTER 07

上传 Admin,正式发布

验收通过,进入最后一步:发布。发布的人用超级管理员账号登录管理端,打开「客户端管理 → 版本发布」,把安装包上传上去,选择对应的环境(正式包选正式环境,常规包选常规环境),核对页面显示的环境、大小、SHA-256 跟本地清单一致,然后点「发布」。

发布之后,旧的当前版本自动变成「已替代」。已经装了旧版的员工,下次打开客户端,就会走「发现更新 → 下载 → 重启并更新」的流程,自动升级到新版。

01 同版本修订:同一个版本号要发一个修复包是允许的,但必须生成一个 SHA-256 不同的新安装包。客户端会提示「同版本修订」,装完后不会再重复提示同一个哈希。

02 版本不能降级:不允许发布比历史最高版本还低的包,也不允许客户端降级。这是铁律。

03 环境严格隔离:正式环境和常规环境的发布记录、下载缓存都是分开的,绝不会串包。


▲ 上传 Admin:选环境、核对哈希、发布

CHAPTER 08

出错了怎么办

再严谨的流程,也可能出岔子。所以打包发布流程里,还专门设计了「兜底」机制。

发错了,立即下架

一旦发现发布错了,马上在管理端下架,客户端就无法再发现或下载这个错误版本。

下载中断,自动续传

员工下载更新时网络断了,会保留一个 .part 临时文件,下次重新下载时自动续传,不会从头再来,也不会跟同版本的其他修订串包。

哈希不匹配,自动删除

下载下来的文件 SHA-256 对不上,客户端会直接删掉这个损坏文件,不会执行安装。

上传失败,有排查指引

上传时返回 413 错误,说明安装包超过 1GB 或者反向代理限制了上传大小,照着提示改就行。

这些兜底机制,让整个发布流程即使出了意外,也能快速止损、快速恢复。


▲ 四套兜底机制:下架 / 续传 / 删除 / 排查

CHAPTER 09

结语

把整条链路串起来看,你会发现一个很有意思的对比:对员工来说,装 WorkMate 就是「双击一个 .exe,点几下下一步」;但对交付 WorkMate 的人来说,这个 .exe 背后,是一整套严谨的打包与发布流程——定版本、隔离环境、一条命令打包、层层安全设防、反复验收、上传发布、出错兜底。

这两者并不矛盾,反而是一体两面。正因为打包环节把复杂、风险、安全都消化干净了,员工端才能做到「开箱即用、双击就装」。

CONCLUSION

那个看似简单的 .exe,其实一点都不简单——它是「安全、可控、好用」这三个词,在交付环节最具体的一次落地。

有了这套流程,企业才能真正放心地把 WorkMate,装到每一个员工的电脑上。



把复杂留在幕后,把简单留给使用的人

定版本 · 隔离环境 · 一条命令 · 四道防线

点赞 · 在看 · 收藏 三连,我们下篇见


【声明】内容源于网络
0
0
兆企供应链综合服务平台
兆企供应链平台专注于为工业企业上下游设计和提供供应链服务产品,以科技创新、赋能供需、链接产业、服务实体为宗旨,以工业原材料购销、仓储监管、物流运输、商品价格管理、贸易风险防范为兆企供应链服务平台的定位,深耕塑料、化工等工业原材料领域。
内容 91
粉丝 0
兆企供应链综合服务平台 兆企供应链平台专注于为工业企业上下游设计和提供供应链服务产品,以科技创新、赋能供需、链接产业、服务实体为宗旨,以工业原材料购销、仓储监管、物流运输、商品价格管理、贸易风险防范为兆企供应链服务平台的定位,深耕塑料、化工等工业原材料领域。
总阅读2.2k
粉丝0
内容91