Coroid您的 AI 软件工厂
文档

版本发布

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

该平台可将任务和计划转化为经过审核的 pull request。一旦这些 pull request被合并，即可生成发布会解答下一个问题：这些工作究竟在哪些环境中运行，且放到那里是否安全？

一次发布会锁定某一个精确的Git提交，并跟踪其在各环境中的运行情况，比如预发环境和生产环境。该提交可能早已位于部署分支上，或者由 Coroid 先将多个未合并的pull request打包成一个发布 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. 按常规流程为每个环境完成这四个步骤，再进入下一个环境。

打包未处理的Pull Request

当有多个来自 Coroid 或您团队的Pull Request等待发布且需一同交付时，可使用此功能。

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

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

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

压缩合并或变基合并也支持，但您的代码托管平台不会将原始Pull Request标记为已合并。Coroid 会通过评论形式关闭这些Pull Request。

发布主分支上的内容

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

  1. 选择新建发布，挑选提交，通常是部署分支上的最新提交。
  2. 在对比对象中，挑选您即将替换的环境。Coroid 会列出该环境当前运行内容与您的提交之间的Pull Request和提交，并筛选出可验证的内容。
  3. 如果您愿意，可留空名称和版本。Coroid 会根据日期和简短提交信息命名发布，项目的版本来源会自动填充版本号。每个发布还会获得下一个构建编号。
  4. 创建发布并完成这四个步骤。

如果您的流水线在每次合并时都会触发部署，或者有人手动部署而未经过Coroid的审核，它仍然可以记录每次部署情况。当某个提交没有对应的已发布版本时，Coroid会为其创建一个观测到的版本，并明确标注该版本未通过Coroid的检查。版本号会采用流水线报告的数值；若Coroid负责分配项目版本，则会采用下一个版本号(1.4.1之后1.4.0)，以及下一个构建编号。

紧急修复部署

所有者或管理员可以开启这是热修复创建版本时，只需固定该修复对应的完整提交信息，并说明为何无法按常规时间流程处理即可。热修复遵循各环境的热修复规则，可能需要的审批环节更少。质量检查和必填清单项仍会生效，且只有所有者和管理员有权审批热修复。

故障恢复

如果健康度检测步骤显示需予以关注，请打开健康度进入受影响的环境，选择较早的正常运行的提交进行重新部署。恢复与版本发布流程涵盖了相关选项，包括无法反馈结果的流水线场景。

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

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

同步发布多个项目

版本发布流程可将必须同步发布的多个项目的版本归为一组，按序执行，例如API及其依赖的应用。详见恢复与版本发布流程。

Coroid的功能与局限

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