06 · 质量门禁与部署
quality.sh 全量门禁、单机生产拓扑、发布闭环与 HTTPS 证书——代码怎么安全地跑到线上
💡 TL;DR：一条纪律贯穿始终——所有质量检查在合并前跑完，红了的代码物理上进不了生产。生产环境是一台云服务器（Docker Compose 编排）+ nginx 边缘分发，发布 = push 触发「全量门禁 → 出制品 → 部署」的自动闭环。
一、全量门禁：quality.sh
本地一条命令 bash ./scripts/quality.sh，与 CI 执行完全相同的检查序列：
设计要点：把关是物理性的——流水线先跑门禁、后出制品包，红 = 没有可部署产物。不存在「红着但部署了」的路径。日常开发只跑受影响包的增量检查（秒级~分钟级），全量交给 push 后的流水线。
二、生产拓扑：单机起步
一台云服务器上 Docker Compose 编排四个容器（nginx 是宿主进程），资源护栏（swap、日志轮转）平滑吸收内存尖峰。这个规模下单机完全够用，架构上把 web/tools/api 拆成独立容器，是为了将来横向扩容时可以原样搬走。
三、发布闭环
三道设计值得注意：
- push 和部署是两道独立的令：合并到主干不等于上线，生产发布永远多一次人工确认；
- 制品完整性自证闭环的破解：校验文件和被校验的包在同一份制品里（能改包的人也能改校验和），所以部署机先用内置公钥验证流水线私钥对清单的签名（闸门⓪），再验 sha256——外部锚点；
- 健康检查与自动回滚：部署后 135 秒窗口内持续探测 web/api/tools 三路，任一路红就自动回滚到上一版制品——「部署搞挂生产」的时间窗口被压到分钟级。
四、HTTPS 证书
通配符证书 *.guangmin.top（一个证书覆盖所有子域名），acme.sh 走 DNS-01 校验自动签发与续期，续期后自动重载 nginx。子域名新增站点零证书改动。证书签发信息在证书透明度日志（CT Log，公开的签发记录库）中可查，免费方案 + 全自动续期符合单机运维定位。
五、复盘：这套部署体系的演进路径
单机起步不等于永远单机。已预留的扩展点：web/tools/api 各自独立容器可分别迁移；PostgreSQL 可平滑换托管实例；OSS 本就异地。当前规模下不为「以后可能」预付复杂度——运维面越大，出事的概率越大，这是单人维护项目的生存法则。