版本发布设置按项目划分。打开版本发布，选择版本发布设置，然后挑选对应项目。共有四个页面，每个页面解答一个问题。
- 运行环境
- 发布将流向哪些环境？ 添加目标环境并按顺序排定。
- 审批规则
- 哪些条件必须首先满足？ 各环境对应的审批流程、角色权限、检查清单及热修复规则。
- 部署流水线
- 由谁执行部署？CoRoid 如何接收反馈？ 您的流水线或 CoRoid 启动部署；通过报告令牌，CI/CD 可确认部署结果。
- 版本管理
- 这是哪个版本？ 版本来源、构建接收的内容，以及 CoRoid 如何验证实际运行的内容。
只有所有者和管理员才能修改版本发布设置，其他人仅可查看。需先关联代码仓库，因为每次版本发布都指向仓库中的某个提交。
环境
版本发布会流向何处？顺序又是怎样的？
每个项目默认包含生产环境。如需添加其他部署目标，比如预发环境或测试环境，可点击添加环境为每一项任务命名。CoRoid 会根据名称生成对应的键，例如：staging。当流水线上报部署信息时，CI/CD会使用该键，因此一旦流水线开始使用，请务必保持键的稳定性。
通过紧随其后来设定顺序。若预发环境紧随其后，生产环境又排在预发环境之后，则部署路径为预发环境 › 生产环境。版本发布页面会按此顺序展示发布流程，审批规则也可要求前序环境部署成功后方可继续。
审批规则
版本发布到此处前需满足哪些条件？
首先选择顶部的环境。规则按环境区分，因此预发环境的要求可相对宽松，生产环境则需更严格。
- 所需审批数：需要不同人员审批的数量。设为0时，只要检查通过即可直接部署。
- 可审批人员：具备审批权限的组织角色。
- 申请人与审批人需分开：发起部署的人员不能兼任审批人，编辑版本发布说明的人员也不能审批该说明。
- 质量检查通过：始终启用。项目的质量图谱会针对该提交触发
release_validation，需从项目的质量设置中发布该图谱。 - 先前环境优先：版本发布必须先部署到其前序环境方可继续。
- 已审批的版本发布说明：当前说明需经审批，后续任何编辑也需重新审批。
- 检查清单：在版本发布页面上由相关人员确认的手动步骤，比如“数据库迁移已审核”。可标记某项为必填或可选。必填项允许设置临时例外情况：所有者或管理员需记录原因及最长24小时的有效期，该例外仅适用于特定的提交和环境。
- 热修复规则：针对紧急修复的宽松规则：审批数量要求以及是否仍需满足先前环境和说明审批的条件。质量检查和必填的检查清单项始终生效，且只有所有者和管理员才能审批热修复。
选择发布规则以保存。发布操作会生成规则的新版本。旧版本下的已获批事项会失效，因此正在进行的版本发布会重新请求审批。没有已发布规则的环境无法通过相关检查，页面也会提示这一点。
部署流水线
谁发起部署？CoRoid 又是如何知晓部署结果的呢？
首先选择顶部的环境，然后指定部署的启动方式：
- 我的流水线自行部署：无需更改现有流程。当你的CI/CD上报部署信息，或所有者、管理员在发布页面记录外部部署时，CoRoid 会同步记录相关部署数据。
- CoRoid 会启动GitHub Actions工作流。或CoRoid 会启动GitLab的CI/CD流水线。：仅当项目代码库位于对应服务商平台时才会显示该选项。需输入指向发布提交的分支或标签、GitHub的工作流文件，以及部署任务的准确名称。CoRoid 会在启动运行前校验引用，并在确认成功前校验指定任务。
在部署报告为环境创建报告令牌，并将其作为机密项存储在CI/CD中。CoRoid 仅展示一次令牌内容，后续只会保留其哈希值。替换令牌会立即停用旧令牌。同一界面还会显示端点地址、项目ID、环境密钥以及流水线所需的相关信息，同时可查看报告是否正常接收。部署事件与CI配置中包含了事件格式及示例。
版本管理
本次发布属于哪个版本？构建过程如何获取该版本号？
可选择每个版本的来源：CoRoid 可推荐下一个版本，也可从代码库中的文件读取版本信息，或由流水线直接上报版本号。每个版本还会分配递增的构建编号。界面会列出CoRoid 传递给流水线的参数，支持通过“新任务”功能申请将其加入构建流程，同时可针对每个环境获取版本URL，以便CoRoid 确认各环境运行的版本。将版本号纳入构建流程包含网页、服务器、Docker、iOS 和 Android 构建的详细信息和操作指南。
在不同组织间迁移设置
设置导出与导入功能会携带环境及其顺序、流水线配置、版本管理规则、版本URL以及已发布的规则（含热修复规则）。但报告令牌和构建编号不会被导出。导入后需重新创建令牌；每个项目会独立维护自身的构建编号。