企业官网建设流程全解析

OpenDisplay 发布自动化：Conventional Commits 加 release-please 自动生成版本的完整指南

【免费下载链接】opendisplayFree, open-source Sidecar/Duet alternative — use your iPhone, iPad or Mac as a true second monitor for your primary Mac over USB or WiFi. Low latency H.264, Retina HiDPI, touch input.项目地址: https://gitcode.com/GitHub_Trending/op/opendisplay

OpenDisplay 是一款免费的开源「副屏 / 虚拟显示器」工具：它把闲置的 iPhone、iPad 或 Mac 通过 USB 或 Wi-Fi 变成 Mac 的第二块显示器，是 Apple Sidecar、Duet Display 的自托管替代方案，支持 Retina 高清与触控输入。本文带你完整看懂它的发布自动化流水线：如何用 Conventional Commits 规范 + release-please 自动判断版本号、打标签、生成 Changelog，再自动构建、公证并分发双平台应用——全程零人工干预。

为什么副屏应用也需要「一键发布」

OpenDisplay 是双平台应用：Mac 端（macOS 14+）和 iOS 端（App Store / TestFlight）。每次版本迭代都要走完整链路：生成 Xcode 工程、签名构建、公证（notarize）、打包 DMG、上传发布、更新自动更新源。如果手动操作，任何一步出错都可能让发布卡住。

这套流水线的核心思路只有一句话：人只负责合并代码，机器负责其余一切。核心文件如下：

第一道关卡：PR 标题强制 Conventional Commits

自动化能否成立，取决于提交信息是否规范。OpenDisplay 采用 squash-merge 合并方式，PR 标题就是提交信息，而 release-please 正是靠解析这些类型来决定版本号怎么升。

仓库专门配置了 pr-title.yml 工作流，每次 PR 打开或改标题时都会运行，非规范标题直接打回。它允许 11 种标准类型：

• feat新功能、fix修复、perf性能优化
• refactor重构、docs文档、test测试
• build构建、ci持续集成、chore杂务、style样式、revert回滚

这个检查不是「最好有」，而是「必须有」。配置文件里的注释还记录了一次真实教训：某个 PR 标题不规范导致功能发布时漏写 Changelog、版本号只升了补丁位，直到人工阅读发布内容才发现——一次疏忽，整个版本日志都受影响，所以才把它做成硬性关卡。

核心引擎：release-please 自动决定版本号

真正的主角是 release.yml 工作流，它在推送 main 分支时触发，第一步就是运行 release-please 动作（release-type: simple）。它的工作原理非常直观：

1. 扫描上两个 tag 之间的所有 Conventional Commits 提交
2. 决策：出现feat就升 minor（如 1.18.0 → 1.19.0），只有fix/chore就升 patch
3. 执行：自动打 tag、创建 Release、写入 CHANGELOG.md 并回推

打开项目里的 CHANGELOG.md 就能看到成果：每个版本都有日期、特性/修复分类、PR 编号与提交哈希，全部机器生成。

一个容易被忽略的细节是并发锁：流水线设置了concurrency组且永不取消运行中的任务。原因是两次快速合并可能同时触发两次发布，而发布任务可能正处于上传 TestFlight 的关键时刻，中途取消会造成脏状态。对新手来说这是很好的工程范例——自动化不仅要跑得快，还要跑得稳。

从 tag 到安装包：fastlane 自动构建公证

release-please 打出 tag 后，build-ios和build-mac两个任务才会启动（release_created == 'true'时才执行），它们都由 fastlane 驱动，具体定义在 Fastfile 中：

• ios beta：签名后构建 iOS 应用并自动上传 TestFlight
• mac build_release：构建 Developer ID 签名并公证的主应用，产出OpenDisplay.dmg
• mac build_receiver_release：同款流水线产出独立的OpenDisplay Receiver应用——把另一台闲置 Mac 也变成显示器

两个版本号都来自同一次发布：营销版本号取 tag 名（去掉v前缀），构建号直接用 CI 运行序号，保证每次构建号单调递增。构建完成后，DMG 会被gh release upload挂到该 tag 的 Release 页面上，用户直接下载。

额外一步：自动生成 Sparkle 自动更新源

macOS 用户最在意的是「装完还能不能自动更新」。OpenDisplay 的答案在发布流水线的最后一步：用 Sparkle 的官方工具为两个 Mac 应用分别生成appcast.xml与appcast-receiver.xml，签名后提交到public/目录（如 public/appcast.xml）。

这个目录变更会再次触发 pages.yml 工作流，重新部署项目站点，更新源即刻生效。整条链是：

合并代码 → 自动定版本 → 自动公证分发 → 自动更新源 → 用户 App 内点「检查更新」

更贴心的是：如果维护者还没配置 Sparkle 签名密钥，这一步会优雅跳过而不是让发布失败——自动化的容错设计同样值得学习。

新手能直接抄的三个实践

1. 标题即契约：把 Conventional Commits 做成 CI 硬性检查（参考 pr-title.yml），从源头保证版本日志可靠
2. 让工具决定版本号：不要手动改版本号，让 release-please 根据提交类型自动升降（参考 release.yml 的release-please步骤）
3. 发布即分发：fastlane 通道统一封装「签名 → 公证 → 打包 → 上传」，一次 tag 触发双平台全流程（参考 Fastfile）

对 OpenDisplay 这样的开源副屏项目来说，这套自动化让「发版」从一件需要专人盯守的体力活，变成了合并代码后自动完成的例行公事——这正是普通用户能持续快速收到稳定新版本的底层原因。

【免费下载链接】opendisplayFree, open-source Sidecar/Duet alternative — use your iPhone, iPad or Mac as a true second monitor for your primary Mac over USB or WiFi. Low latency H.264, Retina HiDPI, touch input.项目地址: https://gitcode.com/GitHub_Trending/op/opendisplay