计划

一个计划是一组按顺序排列、被划分为多个阶段的任务集合。在编写代码前，你需要先对其进行审批。

当工作涉及按特定顺序进行的多次变更，或者你想在确定执行方案前先了解整体思路时，便可创建此类计划。

生命周期#

规划本身是一个独立的阶段，并非瞬间即可完成的转换过程。

1. 规划由此启动。一旦请求通过资格审核，架构师便会分析代码库并起草各阶段及任务。除非请求附带附件或采用了SDLC工作流程，否则规划会自动启动；若满足上述条件，则需在你创建计划或完成准备工作后才会启动。
2. 你需对草稿进行评审。这是整个系统中成本最低的干预节点。
3. 审批、修改或重置。审批后计划即可进入执行阶段；修改会将计划退回给你反馈意见；重置则会重新开始规划流程。
4. 执行阶段。任务会按照顺序执行，同时遵循各阶段的边界限制。

你可以选择一步完成审批和执行，也可以先审批再稍后启动执行。

优先选择修改而非重置#

当计划已接近完善时，修改操作能保留架构师对代码库的认知成果，并将其与你的反馈意见相结合；而重置则会丢弃已有成果并重新起步。

若整体方案有误则可重置，若方案正确但细节有偏差则应修改。修改的成本更低，且被驳回的计划内容并不会丢失——它会成为下一次尝试的输入依据。

控制正在运行的计划#

正在执行的计划可以暂停、恢复或取消，你还能查看各阶段的进度情况。计划也可被克隆，这是复用已验证结构的高效方式——例如将某一迁移操作应用到第二个服务中。

已完成的计划可被归档，以保持活跃视图的清晰度。

仅一个 pull request，而非每个任务对应一个#

计划的各任务不会各自开启一个 pull request。它们会在独立的分支上开展工作，最终合并到共享的车道分支；当工作符合要求时，该分支会作为单个拉取请求推送到你的基准分支。

因此你只需审核一次已组装完成的功能，即可看到全部变更内容，无需逐个批准未完成的阶段。

跨项目计划属于特殊情况：属于不同项目的任务会单独升级，因此每个代码仓库对应一个pull request。一个pull request无法跨越两个代码仓库。

当基础分支发生变动时#

计划可能需要运行数小时，期间你的团队会持续向基础分支合并代码。计划是基于启动时的基础分支状态构建、测试和审核的。等到 pull request 准备就绪时，该分支可能已不再是合并目标。

计划启动时，Coroid 会将基础分支的最新提交记录为计划的基线。在计划的 pull request 能够合并前，Coroid 会再次检查基础分支。文件内容的任何变更都会计入考量，即便计划从未触及这些文件。新的认证机制或安全规则可能会让原本正确的代码失效，却不会引发合并冲突，因此 Coroid 不会等待此类冲突出现。

如果基础分支已发生变动，审批并合并按钮会处于禁用状态，合并审核页面会列出新增的提交及其变更的文件。你可以选择后续操作：

• 接受新的主分支（以你的基础分支命名）——这些变更不会影响当前工作。Coroid 会记录谁接受了哪些提交及原因，该提交也会成为新的基线。如果你查看期间分支再次发生变动，Coroid 会拒绝操作并显示更新的提交内容。任何操作都必须先展示给你确认。
• 合并并重新验证——Coroid 会将基础分支合并到车道分支中，若存在冲突则予以解决。随后它会让该车道分支再次经历开发人员、QA人员和审核人员的流程，对照计划的验收标准和上游提交内容进行检查。审批操作会一直暂停，直到检查完成。只有此时新的提交才会成为基线。若合并或重新验证失败，决策权会交还给你。

默认设置为暂停。项目也可选择“合并并重新验证”模式，这样 Coroid 无需等待你确认就会启动流程；详见代码库和分支设置。重新验证会消耗代理工时。

从开头重新启动的计划会记录新的基准，因此会基于当时的基础分支运行。此前尝试产生的凭证会保留在历史记录中，但不会成为新尝试的当前依据。

强制合并该功能也会跳过此项检查，并记录写入的理由以说明其必要性。详见合并。

阶段与并行处理#

阶段体现的是顺序要求，而非并发执行。若产能允许，同一阶段内的任务可并行运行；下一阶段需等待当前阶段完成。

即便有十个可并行执行的任务且只有一个代理插槽，仍会按顺序逐个运行这些任务。结构本身不会创造产能——详见产能与代理插槽。

计划还是任务？#

在“新任务”表单中，选择计划或任务在创建为之下，或者保持为自动让Qualification自动判定。涉及多个项目的工作始终会被归类为计划。若你选择了某种类型而Qualification建议另一种，在创建任何内容前你会收到相关推荐。

判断标准是是否易于审核：同事能在一坐之下读完的pull request属于任务；需要多步有序变更的则属于计划。

针对规模较大的工作误判为任务的风险更高——任务可能在中途超出容量限制，导致资源浪费。误判为计划则只会多花一步审批流程，并非绝对必要。

交付关卡#

计划可设置交付关卡，用以规定其输出成果推进前必须满足的条件。详见质量关卡。

相关内容#

• 任务、计划、迭代和泳道
• 迭代
• 规格说明
• 来源