PromptX发布流水线揭秘标签驱动CI/CD如何让dev/alpha/beta渐进式发布变简单【免费下载链接】PromptXPromptX · 领先的AI 智能体上下文平台 PromptX · Leading AI Agent Context Platform项目地址: https://gitcode.com/Deepractice/PromptXPromptX 是一个领先的 AI 智能体上下文平台它把专业角色、记忆系统与智能工具通过 MCP 协议注入 Claude、Cursor 等 AI 应用。而支撑这个平台稳定迭代的是一套标签驱动的 CI/CD 发布流水线一个 Git 标签如v1.10.1-beta就能决定包发往 dev、alpha、beta 还是 latest 通道。本文将带你从零看懂这套渐进式发布机制如何工作以及如何把它借鉴到自己的项目里。先认识 PromptX为什么要做渐进式发布PromptX 是一个 pnpm monorepo包含 CLI、桌面端Electron、core、logger、mcp-server 等十余个包。功能更新频繁、用户规模持续增长意味着直接发 stable 风险太大—— 一个坏版本会同时影响 npm 用户和桌面端用户回滚成本高—— 需要先让内部用户和小众用户验证新特性多产物发布—— 同一次发布要产出 npm 包、Docker 镜像、Mac/Win/Linux 桌面端安装包。于是 PromptX 采用了经典的多通道策略dev开发版→ alpha内测版→ beta公测版→ latest正式版每个通道对应一个 npm dist-tag用户可以按需尝鲜。完整流程文档见 docs/RELEASE_GUIDE.md。发布流水线全景5 条工作流各司其职所有流水线定义在 .github/workflows/ 目录下核心分工如下工作流文件触发方式职责Start Releaserelease-start.yml手动按钮计算版本号、创建 release 分支和 PRAuto Tagrelease-auto-tag.ymlrelease PR 合并自动打v*标签并推送Publish Releaserelease-publish.yml推送v*标签发布 npm 包 Docker 镜像Desktoprelease-desktop.yml推送v*标签构建 Mac/Win/Linux 桌面端Hotfixhotfix.yml手动按钮基于旧标签拉出紧急修复分支一句话概括整条链路点一下按钮 → 自动开 PR → 合并即打标签 → 标签决定发布到哪个通道。人工操作只有两步点击开始发布和合并 PR其余全部自动化。一键启动发布Start Release 如何计算版本号在 Actions 页面手动运行 Start Release 工作流后release-start.yml 会完成四件事检查 changesets—— 开发者提交代码时运行pnpm changeset记录哪个包、升了什么版本、改了什么。没有变更记录时会给出警告计算版本号—— 支持填入自定义版本号留空则交给 changesets 根据提交记录自动推算如1.9.0 → 1.10.0创建 release 分支—— 自动建出release/1.10.0分支并把所有 workspace 包的版本号更新到该值自动开 PR—— 生成带发布检查清单的 Pull Request等你 Review 后合并。这个设计的巧妙之处在于版本号不是发布时才想起来的而是开发时就通过 changesets 沉淀下来的发布流程自然顺畅。合并即打标签Auto Tag 消除手工 git tag传统流程里合并发布 PR 后要手动执行git tag v1.10.0 git push容易忘、容易拼错。PromptX 用 release-auto-tag.yml 把这一环彻底自动化监听 main 分支上以release/开头且标题以 Release v开头的 PR 合并事件从分支名release/1.17.1中直接提取版本号创建带注释的 tagv1.17.1并推送tag 已存在则跳过天然幂等最后在 PR 下留一条评论告诉团队哪些自动化动作已被触发。推送 tag 的瞬间Publish Release 与 Desktop 两条流水线同时被点燃——标签就是整个 CI/CD 的总开关。标签如何决定发布通道dev/alpha/beta/latest 四路分流release-publish.yml 在收到v*标签后核心逻辑是看标签后缀选 npm dist-tag标签示例是否预发布npm dist-tag说明v1.10.0否latest正式通道新用户默认装到它v1.10.1-beta是beta公测通道v1.10.1-alpha是alpha内测通道v1.10.1-rc是rc候选发布通道这样用户只需一条命令就能选择口味npm install promptx/clibeta装公测版不带后缀则装正式版。这套机制还有三个值得抄作业的细节beta 版本号自动自增推送v1.10.1-beta后流水线会查询 npm 上已发布的1.10.1-beta.*自动递增出1.10.1-beta.1、1.10.1-beta.2……同一个 beta 标签反复推送也不会版本冲突预发布标记透传beta/alpha/rc 标签创建的 GitHub Release 自动打上 prerelease 标记桌面端构建同样识别release-desktop.yml避免内测包混入稳定版下载页npm 与 Docker 解耦Docker 镜像只在正式版非 prerelease时构建且 AMD64 与 ARM64并行编译、最后合并为多平台 manifest构建前还会轮询等待 npm 包真正可下载避免镜像引用了不存在的版本。旧用户不迷路dev 通道与 dpml-prompt 同步除了 alpha/betaPromptX 还有一个dev通道。在 sync-dpml-prompt.yml 中可以看到每次发版都会把旧版 CLI 包dpml-prompt现已废弃的包装包同步发布到dev、alpha、beta、latest 四个 dist-tag保证老配置的用户升级路径平滑。这正是渐进式发布的另一层含义新版本向新通道前进旧通道不断有内容同步用户随时能跟上。紧急修复Hotfix 分支一键生成发现线上问题不用等下个迭代。hotfix.yml 让你输入目标版本如1.9.1和基础标签如v1.9.0流水线就会从旧标签拉出hotfix/1.9.1分支、更新版本号并自动开 PR。合并后走同样的打标签 → 发布链路紧急修复与常规发布共用一套基础设施。清单如何给你的项目复刻这条流水线想在自己的开源项目里落地类似的标签驱动 CI/CD可以按这份清单推进✅用 changesets 记录变更让版本号来自开发过程而非发布时拍脑袋✅release 分支 PR 作为质量门发布前必经 Review 与测试✅合并即打标签由 bot 自动创建并推送 tag消灭手工git tag✅标签后缀映射 dist-tag-beta→ beta、-alpha→ alpha、无后缀 → latest用一张映射表分流✅预发布版本号自动递增解决同一通道重复发版的冲突✅稳定通道才构建重资产Docker 多架构镜像只在 latest 时构建并并行提速✅下游依赖等待上游就绪轮询npm view确认包可用后再构建依赖它的产物。相关文件索引发布流程指南docs/RELEASE_GUIDE.md启动发布.github/workflows/release-start.yml自动打标签.github/workflows/release-auto-tag.ymlnpm Docker 发布.github/workflows/release-publish.yml桌面端构建.github/workflows/release-desktop.yml紧急修复.github/workflows/hotfix.ymldev 通道同步.github/workflows/sync-dpml-prompt.yml总结PromptX 的发布流水线把发布这件高风险的事拆解为可重复、可追溯、低人工的自动链路——标签是唯一开关通道是多道保险。理解并复刻这套机制你的项目也能拥有从容的渐进式发布能力。【免费下载链接】PromptXPromptX · 领先的AI 智能体上下文平台 PromptX · Leading AI Agent Context Platform项目地址: https://gitcode.com/Deepractice/PromptX创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PromptX发布流水线揭秘：标签驱动CI/CD如何让dev/alpha/beta渐进式发布变简单
PromptX发布流水线揭秘标签驱动CI/CD如何让dev/alpha/beta渐进式发布变简单【免费下载链接】PromptXPromptX · 领先的AI 智能体上下文平台 PromptX · Leading AI Agent Context Platform项目地址: https://gitcode.com/Deepractice/PromptXPromptX 是一个领先的 AI 智能体上下文平台它把专业角色、记忆系统与智能工具通过 MCP 协议注入 Claude、Cursor 等 AI 应用。而支撑这个平台稳定迭代的是一套标签驱动的 CI/CD 发布流水线一个 Git 标签如v1.10.1-beta就能决定包发往 dev、alpha、beta 还是 latest 通道。本文将带你从零看懂这套渐进式发布机制如何工作以及如何把它借鉴到自己的项目里。先认识 PromptX为什么要做渐进式发布PromptX 是一个 pnpm monorepo包含 CLI、桌面端Electron、core、logger、mcp-server 等十余个包。功能更新频繁、用户规模持续增长意味着直接发 stable 风险太大—— 一个坏版本会同时影响 npm 用户和桌面端用户回滚成本高—— 需要先让内部用户和小众用户验证新特性多产物发布—— 同一次发布要产出 npm 包、Docker 镜像、Mac/Win/Linux 桌面端安装包。于是 PromptX 采用了经典的多通道策略dev开发版→ alpha内测版→ beta公测版→ latest正式版每个通道对应一个 npm dist-tag用户可以按需尝鲜。完整流程文档见 docs/RELEASE_GUIDE.md。发布流水线全景5 条工作流各司其职所有流水线定义在 .github/workflows/ 目录下核心分工如下工作流文件触发方式职责Start Releaserelease-start.yml手动按钮计算版本号、创建 release 分支和 PRAuto Tagrelease-auto-tag.ymlrelease PR 合并自动打v*标签并推送Publish Releaserelease-publish.yml推送v*标签发布 npm 包 Docker 镜像Desktoprelease-desktop.yml推送v*标签构建 Mac/Win/Linux 桌面端Hotfixhotfix.yml手动按钮基于旧标签拉出紧急修复分支一句话概括整条链路点一下按钮 → 自动开 PR → 合并即打标签 → 标签决定发布到哪个通道。人工操作只有两步点击开始发布和合并 PR其余全部自动化。一键启动发布Start Release 如何计算版本号在 Actions 页面手动运行 Start Release 工作流后release-start.yml 会完成四件事检查 changesets—— 开发者提交代码时运行pnpm changeset记录哪个包、升了什么版本、改了什么。没有变更记录时会给出警告计算版本号—— 支持填入自定义版本号留空则交给 changesets 根据提交记录自动推算如1.9.0 → 1.10.0创建 release 分支—— 自动建出release/1.10.0分支并把所有 workspace 包的版本号更新到该值自动开 PR—— 生成带发布检查清单的 Pull Request等你 Review 后合并。这个设计的巧妙之处在于版本号不是发布时才想起来的而是开发时就通过 changesets 沉淀下来的发布流程自然顺畅。合并即打标签Auto Tag 消除手工 git tag传统流程里合并发布 PR 后要手动执行git tag v1.10.0 git push容易忘、容易拼错。PromptX 用 release-auto-tag.yml 把这一环彻底自动化监听 main 分支上以release/开头且标题以 Release v开头的 PR 合并事件从分支名release/1.17.1中直接提取版本号创建带注释的 tagv1.17.1并推送tag 已存在则跳过天然幂等最后在 PR 下留一条评论告诉团队哪些自动化动作已被触发。推送 tag 的瞬间Publish Release 与 Desktop 两条流水线同时被点燃——标签就是整个 CI/CD 的总开关。标签如何决定发布通道dev/alpha/beta/latest 四路分流release-publish.yml 在收到v*标签后核心逻辑是看标签后缀选 npm dist-tag标签示例是否预发布npm dist-tag说明v1.10.0否latest正式通道新用户默认装到它v1.10.1-beta是beta公测通道v1.10.1-alpha是alpha内测通道v1.10.1-rc是rc候选发布通道这样用户只需一条命令就能选择口味npm install promptx/clibeta装公测版不带后缀则装正式版。这套机制还有三个值得抄作业的细节beta 版本号自动自增推送v1.10.1-beta后流水线会查询 npm 上已发布的1.10.1-beta.*自动递增出1.10.1-beta.1、1.10.1-beta.2……同一个 beta 标签反复推送也不会版本冲突预发布标记透传beta/alpha/rc 标签创建的 GitHub Release 自动打上 prerelease 标记桌面端构建同样识别release-desktop.yml避免内测包混入稳定版下载页npm 与 Docker 解耦Docker 镜像只在正式版非 prerelease时构建且 AMD64 与 ARM64并行编译、最后合并为多平台 manifest构建前还会轮询等待 npm 包真正可下载避免镜像引用了不存在的版本。旧用户不迷路dev 通道与 dpml-prompt 同步除了 alpha/betaPromptX 还有一个dev通道。在 sync-dpml-prompt.yml 中可以看到每次发版都会把旧版 CLI 包dpml-prompt现已废弃的包装包同步发布到dev、alpha、beta、latest 四个 dist-tag保证老配置的用户升级路径平滑。这正是渐进式发布的另一层含义新版本向新通道前进旧通道不断有内容同步用户随时能跟上。紧急修复Hotfix 分支一键生成发现线上问题不用等下个迭代。hotfix.yml 让你输入目标版本如1.9.1和基础标签如v1.9.0流水线就会从旧标签拉出hotfix/1.9.1分支、更新版本号并自动开 PR。合并后走同样的打标签 → 发布链路紧急修复与常规发布共用一套基础设施。清单如何给你的项目复刻这条流水线想在自己的开源项目里落地类似的标签驱动 CI/CD可以按这份清单推进✅用 changesets 记录变更让版本号来自开发过程而非发布时拍脑袋✅release 分支 PR 作为质量门发布前必经 Review 与测试✅合并即打标签由 bot 自动创建并推送 tag消灭手工git tag✅标签后缀映射 dist-tag-beta→ beta、-alpha→ alpha、无后缀 → latest用一张映射表分流✅预发布版本号自动递增解决同一通道重复发版的冲突✅稳定通道才构建重资产Docker 多架构镜像只在 latest 时构建并并行提速✅下游依赖等待上游就绪轮询npm view确认包可用后再构建依赖它的产物。相关文件索引发布流程指南docs/RELEASE_GUIDE.md启动发布.github/workflows/release-start.yml自动打标签.github/workflows/release-auto-tag.ymlnpm Docker 发布.github/workflows/release-publish.yml桌面端构建.github/workflows/release-desktop.yml紧急修复.github/workflows/hotfix.ymldev 通道同步.github/workflows/sync-dpml-prompt.yml总结PromptX 的发布流水线把发布这件高风险的事拆解为可重复、可追溯、低人工的自动链路——标签是唯一开关通道是多道保险。理解并复刻这套机制你的项目也能拥有从容的渐进式发布能力。【免费下载链接】PromptXPromptX · 领先的AI 智能体上下文平台 PromptX · Leading AI Agent Context Platform项目地址: https://gitcode.com/Deepractice/PromptX创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考