全程可审计原生 GitHub 工作流现有检查仍掌握决定权每个任务的成本清晰可见
发布是最后被自动化的环节,也最容易出错
多数团队实现了构建自动化,却把发布决策、更新日志与版本标签留给记得处理的人。developerz.ai 读取自上次发布以来合并的内容,依据实际的 PR 起草发布说明,并在你的策略判定应当发布时创建版本。发布权限始终保留在你的 GitHub App 安装与分支保护之中;我们不会获得额外的发布令牌,每一个发布操作都是一条审计记录。
发布说明来自合并记录,而非记忆
更新日志依据自上次发布以来实际合并的 PR 起草。
发布节奏写在策略文件中
每个代码仓库的发布规则与其他配置一同保存在 maintainer.yml 中,像其余配置一样在仓库中进行版本管理。
与其他操作一样可审计
每次发布都是一条附有执行者与理由的操作记录,而不是某人按下的一个无从追溯的按钮。
何时暂停并征询你
它打标签,由你的 CI 发布
它从不发布到软件包仓库:npm、crates、PyPI 和 RubyGems 均被拒绝,因为在这些地方发布意味着要持有你的令牌,所以由你自己的 CI 基于它推送的标签进行发布。没有提交 maintainer.yml 的仓库不会发布任何版本。如果仓库有标签,但没有一个是稳定的 X.Y.Z 版本(可带前缀 v),同样不会发布:不会运行任何任务,而是创建一个阻塞项,请你打一个基线标签或关闭发布,而不是自行编造版本号。完全没有标签的仓库会发布第一个版本。使用 bump_strategy: bump_pr_first 时,版本号升级会以 PR 形式发起,并与其他 PR 一样经过合并门禁,包括 pr.human_merge。
查看发布设置