Coroid您的 AI 软件工厂
文档

版本发布

从合并到生产环境，全程追踪某一指定提交，包含各项检查、审批以及实际部署的证明。

该平台可将任务和计划转化为经过审核的拉取请求。一旦这些请求被合并，便会触发一个版本发布接下来要回答的问题是：这些工作究竟在哪些环境中运行，且部署到那里是否安全？

版本发布会锁定某一个指定的Git提交，并跟踪其在各环境中的运行情况，例如先经过预发环境再进入生产环境。该提交可能早已位于部署分支上，或者由Coroid先将未合并的拉取请求打包成一个版本发布pull request，其合并提交即为版本发布的依据。在每个环节，Coroid都会检查该提交、收集你要求的审批结果，并记录下CI/CD反馈的部署信息。Coroid绝不会仅凭自身判断就标记版本已部署。必须由你的流水线或人工确认外部部署情况后，才会判定部署成功。

Coroid 平台

  1. 任务或计划

    智能体负责规划、构建和测试

  2. 拉取请求

    经审核并提供相关依据

  3. 已合并

    由您或仓库规则执行合并

发布

  1. 发布

    一个指定的提交

  2. 预发布环境

    检查 · 审批 · 部署

  3. 生产环境

    检查 · 审批 · 部署

该平台产出经过审核并合并的成果。一次发布基于一个已合并的提交，并依次经过各环境。

一分钟了解核心概念

  • 版本发布：一个提交、一个名称，以及可选的版本号。例如 2.4.0版本号属于可选项，因此无需标签也能实现持续交付。
  • 环境：通往用户面前的必经环节，比如预发环境或生产环境。每个项目可自行定义这些环节及其顺序。
  • 灰度发布：版本发布目前已覆盖的环境范围。
  • 工作内容：版本发布中规划的任务以及已合并的变更内容，会以已完成/总任务数的形式展示。
  • 每个环境的四个步骤：检查项、审批、部署和健康检查。版本发布页面会直接显示需要你操作的步骤。
  • 打包：该版本由已打开的 pull request 构建而成。Coroid 会按照可自定义的顺序将它们合并到同一个版本分支中，随后生成一条发布 pull request。批量版本还会多出一个第五步操作。打包，位于检查项之前。

快速浏览版本发布信息

打开版本发布功能位于每个项目的主侧边栏中，或者也可通过某个项目的版本发布标签页查看。列表会展示每个版本发布的工作进度、在各环境中的发布范围以及其状态。您可通过标签页切换正在进行的、已发布的或已关闭的版本发布。

选择一个版本发布即可打开其详情页。

  1. 1状态。 发布整体的当前状态。
  2. 2版本发布与工作流程。 目前已覆盖的环境以及已完成的工作规划。选择某个节点即可查看其具体步骤。
  3. 3操作步骤。 所选环境的四个步骤。其中需您介入的步骤为当前开放状态。
  4. 4即将上线的内容。 提交中确认的合并变更、规划的任务以及上次部署后的新增提交。
该发布已到达预发环境，准备部署至生产环境。

发布范围追踪栏也可用于切换。选择其中的某个环境即可查看该环境的四个步骤。页面会默认打开版本发布尚未到达的第一个环境，因此下一步操作通常一目了然。

每个环境的四个步骤

  1. 1检查项

    Coroid

    针对指定提交执行质量检查；必填的检查项均已确认。

  2. 2审批

    您的团队

    根据您的规则指定人员对该提交在此环境下的发布予以审批。

  3. 3部署

    您的 CI/CD

    您的流水线在 Coroid 触发或自主启动后执行部署，并反馈结果。

  4. 4运行状态

    Coroid

    确认部署后，由金丝雀检查对环境进行监控。

每个环境均遵循相同的四个步骤。每一步均会注明执行方。

检查项。点击运行检查项。Coroid会根据该精确提交运行项目的版本发布验证质量图谱，确认所有关联的变更都包含在该提交中。该环境所需的任何检查清单项也必须标记为已完成。若有因素阻碍版本发布，该步骤会列出具体原因。一旦更改提交或关联变更，之前的检查结果便会失效，此时该步骤会提示您重新运行检查。

审批。检查项通过后，符合规则的人员即可进行审批。该步骤会显示所需的审批数量及对应角色。若规则要求审批版本发布说明文档，此类说明也会在此处获批。

部署。当检查项和审批均完成后，版本发布便准备好进入对应环境。若Coroid已与该环境的GitHub Actions或GitLab CI/CD集成，所有者或管理员可点击部署到…，随后Coroid便会针对该精确提交启动流水线。否则，流水线会自行部署并反馈结果。无论哪种情况，只有确认部署成功后，该步骤才会变为绿色。

健康检查。部署成功后，如果您配置了金丝雀质量图谱，Coroid会运行它。金丝雀测试通过则标志着环境健康。若测试失败则会显示需予以关注并提供恢复方案。若没有配置金丝雀测试，环境状态将保持未知，而非默认视为健康。

各状态的含义

状态含义
草稿目前尚未固定任何提交记录。在对应的发布 pull request 被合并前，批量版本会一直处于草稿状态。
正在准备已锁定某个提交；但仍有部分检查项或审批流程尚未完成。
已被阻塞检查项已执行，但有因素阻碍了版本发布流程。
就绪至少一个环境已通过全部检查项和审批流程。目前尚未发生实际部署。
正在发货部署过程正在进行中。
部分已发货该版本已部署到部分环境，但尚未覆盖所有环境。
已发货该版本已成功部署到所有环境。
已失败或已取消版本发布流程已中止，不会继续推进。
历史记录此类记录创建于部署凭证生成之前，不能用作部署已完成的证明。

就绪“就绪”状态绝不意味着已完成部署。只有经过确认的部署才能推动版本在发布流程中前进。

工作流程

为项目配置版本发布规则

每个项目仅需执行一次此操作。打开版本发布，选择版本发布设置，然后选取对应项目。

  1. 在环境中添加各部署节点并按顺序排列，例如先将预发环境排在生产环境之前。

  2. 在审批规则中为每个环境设定发布规则：所需审批数量、对应角色以及检查项。未发布相关规则前，环境无法通过各项检查。

  3. 在部署流水线中选择由Coroid启动部署还是由您的流水线执行。随后创建报告令牌，以便CI/CD能向Coroid反馈实际部署内容。

  4. 在版本管理中选择各版本的来源，并为每个环境设置版本URL，以便Coroid确认该环境运行的具体版本。

版本发布设置系统会引导您完成各界面操作，且将版本信息嵌入构建流程详细说明版本信息如何传递到应用程序中。

发布计划内工作

当您提前确定要一起发布的内容时，可使用此功能。

  1. 在绑定具体提交前即可创建版本，此时版本处于草稿状态。
  2. 为版本设置目标任务，这些任务会显示在 计划任务下，任务完成后进度条会相应填充。
  3. 待任务合并后，选择编辑详情并选取要发布的提交。Coroid会确认该提交包含哪些已合并的变更。
  4. 针对首个环境按照四步流程操作，随后依次处理下一个环境。

打包未合并的拉取请求

当存在大量等待发布的拉取请求，无论是来自Coroid还是您的团队，且需一同发布时，可使用此功能。

  1. 修复结算总额计算问题#12检查通过
  2. 新增订单导出功能#15Coroid任务已批准
  3. 重构搜索索引#18草稿
  1. Coroid的顺序设定将最稳定的内容排在最前。您可以勾选并重新排序。
  2. 一个版本分支，其中拉取请求按序合并。
  3. 一个发布 pull request。一旦合并，其提交内容即会被发布。

通过合并提交将发布 pull request 合并，这样您的供应商就能识别出每个已合并的捆绑 pull request。

Coroid 会规划内容及其顺序。您进行调整后，Coroid 会将拉取请求合并到同一个发布分支中，并生成一个发布 pull request。该合并提交即为本次发布的版本。
  1. 选择新建版本发布，挑选对应项目，然后选择未合并的拉取请求。此选项要求使用GitHub或GitLab类型的代码库，因此由Coroid托管的项目会直接生成对应提交。
  2. Coroid会将未合并的拉取请求按安全性优先级排序后整合到部署分支中。由Coroid创建的pull request会显示为对应的任务或计划。Coroid会综合评估提供方及自身审核结果：包括检查项、评审意见、代码规模、冲突情况以及多拉取请求共同涉及的文件。它会排除草稿状态、检查项未通过、有修改要求的请求以及来自分叉仓库的请求，并说明排除原因。
  3. 取消勾选需要延后的请求，用箭头调整顺序。依赖其他请求的拉取请求（即堆叠式pull request，或标注“依赖于#12”的请求）必须排在被依赖的请求之后。
  4. 选择创建版本发布。Coroid会根据部署分支创建release/<version>，按序合并各拉取请求，并生成一个版本发布pull request，其中会列出并关联每个拉取请求。
  5. 如果 pull request 与发布分支存在冲突，打包步骤会在此处停止并显示相关文件。选择通过 Coroid 解决以让开发者智能体合并该文件并在任务中解决冲突，或者将其排除以便继续后续流程而不包含它。
  6. 请先审核发布 pull request，再使用 进行合并。合并提交。随后，您的提供商会将每个打包的 pull request 标记为已合并。Coroid 会将合并提交固定为发布提交，记录打包的请求作为本次发布的交付内容，并关闭所有仍处于开放状态的请求，同时附上指向发布 pull request 的链接。
  7. 按常规流程为每个环境执行这四个步骤。

压缩合并或变基合并也支持，但您的服务提供商不会将原始拉取请求标记为已合并。Coroid 会通过评论的方式关闭这些请求。

发布主分支上的内容

适用于持续交付场景，即发布所有已合并的内容。

  1. 选择新建版本并选取提交，通常是部署分支上的最新提交。
  2. 在对比对象中选取要替换的环境。Coroid会列出该环境与您的提交之间存在的拉取请求和提交，并筛选出可验证的内容。
  3. 若您不希望设置名称和版本，可直接留空。Coroid会根据日期和简短提交信息命名版本，项目版本来源会自动填充版本号。每个版本还会获得下一个构建编号。
  4. 创建版本并按照四步流程操作即可。

即使您的流水线在每次合并时无需询问Coroid即可直接部署，仍可向该系统反馈每次部署情况。若某提交没有对应的版本记录，Coroid会为其创建观测版版本，并明确标注该版本未通过Coroid的检查。

发布紧急修复补丁

所有者或管理员可启用此为热修复补丁创建版本时选中此项，绑定修复补丁的完整提交，并说明为何无法按常规流程处理。热修复补丁会遵循各环境的热修复规则，所需审批数量可能更少。质量检查和必填检查项仍会生效，且仅所有者和管理员可审批热修复补丁。

故障恢复

若健康检查步骤显示需予以关注，打开健康状态在受影响的环境上选择更早的正常运行的提交进行重新部署。恢复与版本发布流水线涵盖了相关选项，包括无法反馈结果的流水线。

通过聊天工具或编辑器操作

聊天助手和 Coroid 的 MCP 服务器具备相同的发布功能：列出并查看发布版、选择提交、预览即将发布的内容、准备发布版、打包开放中的拉取请求、运行检查、审批、请求部署并起草说明。打包、审批和部署始终需要人工确认。详见聊天助手和Coroid 作为 MCP 服务器。

同步发布多个项目

版本发布流水线会将必须同步发布的多个项目的版本发布按序组合，例如 API 及其依赖的应用。详见恢复与版本发布流水线。

Coroid 的功能与局限

  • Coroid 负责标记、检查和记录。您的代码库和 CI/CD 负责构建和部署。
  • 当 Coroid 对 pull request 进行打包时，它会创建版本分支和发布 pull request。但它不会替您合并该发布 pull request。
  • 仅当您连接了流水线且所有者或管理员请求部署时，Coroid 才会启动流水线。
  • 部署请求并不等同于已验证结果。只有当您的流水线确认成功，或有人记录了已验证的外部部署信息时，发布流程才会推进。
  • 发布说明是供您编辑和审批的草稿。Coroid 不会将其发布到任何地方。
  • 迭代是规划周期，并非部署边界。一个迭代可支撑多个发布版，一个发布版也可包含来自多个迭代的工作内容。