跳到正文

使用场景

不需要一套仪式就能发出去的版本

当已合并的工作量足以支撑一次发布时,agent 会按你提交的策略起草更新日志、切出 tag,而且从不持有你没有授予它的令牌。

Pull request #731

处理过期的 workspace token

就绪
+ if (token.expiresAt < Date.now()) {
+   await rotateWorkspaceToken(token)
+ }
8 个文件改动 · +94 −21策略已通过
全程可审计原生的 GitHub 工作流你已有的检查依然说了算每个任务的成本都看得见

发版是最后才被自动化的一环,也是最容易做错的一环

大多数团队自动化了构建,却把决定、更新日志和打 tag 留给谁想起来谁做。developerz.ai 读取自上次发布以来合并了什么,从真实的 PR 里起草发布说明,并在你的策略认为该发时切出版本。发布权限始终留在你的 GitHub App 安装和你的分支保护里;没有另外一个发布令牌被交给我们,而且每一个发布动作都是一条审计记录。

发布说明来自合并记录,不是来自记忆

更新日志是从上次发布以来真正落地的那些 PR 里起草出来的。

你的节奏,写在策略文件里

每个仓库的发布规则和其他配置一起放在 maintainer.yml 里,像你其余的配置一样在仓库里进版本控制。

和别的事一样可审计

一次发布是一条有执行者、有理由的记录动作,而不是某个人按下的一个看不清的按钮。

深入一层

我们自己在用:我们的更新日志就是由同一条通道、在我们自己的仓库上生成的。

阅读更新日志

让一支 AI 开发者团队开始干活 少维护。

带上你自己的密钥和机器,放一个 .dz/maintainer/maintainer.yml,剩下的交给循环去跑。全程可审计。目前为邀请制。