修改分布式作业平台的单体仓库，并用真实服务进行测试

## 从仓库根目录运行命令，并按软件包类型选择检查 通过固定版本的软件包管理器包装器，从仓库根目录运行工作区命令。在启动应用程序或命令行工具之前，先构建所需依赖项，并使用工作区筛选器将工作限制在受影响的软件包依赖图中。 严格遵循仓库的依赖项安装策略。如果该策略要求先编辑软件包声明再安装，就应这样做，而不要调用绕过可审查版本选择的添加命令。 根据软件包的角色选择验证方式： - 如果应用程序和私有软件包的构建不能证明正确性，则使用静态类型检查。 - 对已发布的软件包使用其实际的软件包构建，以便检验导出项和生成的产物。 - 对重大更改、新文件、模式相关工作和大范围重构执行本地类型检查或构建验证。 - 项目明确允许时，微小编辑可以依靠针对性检查和持续集成。 不要仅仅因为熟悉就运行大范围构建。使用能够在所更改层真正检出失败的检查。 ## 用真实服务容器而不是模拟来测试队列和数据库 将测试与源代码放在一起，并使用仓库唯一支持的测试运行器。从受影响的软件包或单个测试文件开始，仅在工作区要求时先构建其依赖项。 如果项目提供可随时销毁的服务容器，不要用模拟对象替代数据库、队列或缓存。使用能够提供真实连接选项和干净状态的隔离测试辅助工具来测试： - 队列和缓存行为。 - 关系型事务和迁移。 - 跨越存储边界的组合工作流。 为纯函数保留轻量级单元边界。对于基础设施行为，优先使用受控的真实服务，使序列化、时序、重试和事务语义保持可见。 在最终的只读代码检查之前，先运行格式化和自动代码检查修复。优先使用静态导入；仅在存在不可避免的循环、经测量有益的代码拆分或真正的运行时条件时使用动态加载。 ## 记录已发布软件包的更改，并把共享依赖统一为一个版本 每当已发布的软件包或集成功能发生更改时，都要添加带版本的更改记录。修复和小型兼容更改默认采用补丁版本；次版本须与维护者确认；未经明确批准，绝不选择主版本。 对于不涉及已发布软件包更改的纯服务器端行为，使用服务器更改说明机制，而不是软件包版本记录。 面向用户撰写发布说明： - 先说明发生变化的行为。 - 尽可能使用一个通俗的句子。 - 省略内部工具、队列、存储和部署名称。 - 不要把实现方式描述成收益。 当运行时类型同一性依赖于有意共享的依赖项时，应使其在整个工作区中保持同一个精确版本。添加此类依赖项之前，先找到现有的固定版本并与之完全匹配；版本范围或并存版本可能使一个软件包中的模式与另一个软件包的使用方不兼容。 ## 先追踪作业请求的路径，不随意在各层之间移动职责 编辑前先了解请求路径： 1. 外部请求进入API和仪表板应用程序。 2. 服务验证意图并调用运行生命周期引擎。 3. 引擎持久化状态并将工作加入队列。 4. 监管程序认领工作并管理隔离执行。 5. 结果通过生命周期引擎返回。 6. 事务状态和分析事件分别流入各自独立的存储。 将公共SDK、命令行工具、共享类型、构建扩展、客户端钩子、队列工作进程、数据库、分析、调度和执行引擎保留在其声明的软件包中。如果导出契约有此要求，应通过受支持的子路径导入公共共享类型，而不是从宽泛的软件包根路径导入。 不要为了方便而跨这些层移动职责。对调度、队列、执行或持久化的更改必须考虑完整的状态转换和失败路径。 ## 不恢复已停用的执行引擎，并用错误干净地拒绝旧客户端 旧引擎移除后，历史目录名或兼容性枚举仍不足以证明它还在运行。应以当前架构文档和活动的软件包依赖图为权威依据。 绝不要为了满足旧分支或旧请求而重新引入已停用的路径。兼容性处理可以识别过时版本，但只能用来拒绝该版本，或通过客户端错误妥善结束处理；不得将工作路由至不存在的执行代码，也不得把预期的拒绝变成服务器故障。 更改兼容性行为之前： - 跟踪当前启用的引擎选择。 - 确认如何识别过时的客户端。 - 保持明确的错误语义。 - 为当前路径和已停用版本的拒绝都添加测试。 将带版本的SDK指南和生成的代理规则留到各自专门的维护阶段处理。除非任务明确包含这些内容，否则不要更新分发的指令包。 ## 用当前公共SDK编写任务，SDK变化时同步更新文档 通过当前公共SDK入口点定义持久任务。不要导入过时的版本子路径，也不要恢复已弃用的作业定义API。 任务定义应包含： - 稳定的标识符。 - 带类型的输入契约。 - 一个异步运行函数。 - 对无效输入的显式错误。 - 幂等行为，或针对副作用记录在案的重试边界。 即使代码源自命令行软件包，只要它被捆绑进客户执行镜像，也应将其视为公共运行时代码。应同时验证软件包导出项、捆绑的依赖项和容器行为。 SDK契约发生变化时，应更新公共文档和示例。产品文档应保存在指定站点，并遵循该站点的本地格式和导航规则。 ## 在本地构建上把真实任务从头到尾跑通再确认 使用受维护的参考项目，根据本地构建测试SDK和平台更改。将参考项目链接到工作区软件包，避免误将已发布的软件包作为测试对象。 按以下顺序运行流程： 1. 启动所需的存储和队列服务。 2. 应用数据库迁移，并为参考组织和项目填充种子数据。 3. 构建SDK、命令行工具和受影响的软件包。 4. 在后台启动API应用程序并验证其健康检查端点。 5. 从已链接的参考项目启动本地任务工作进程。 6. 等待明确的工作进程就绪信号。 7. 通过受支持的控制界面触发一个代表性任务。 8. 轮询或列出各次运行，直到出现预期的终止状态。 9. 检查返回的结果和持久化的运行状态。 不要仅凭编译就报告端到端成功。保留命令输出或运行标识符作为证据，并在验证结束时停止后台进程。 ## 固定多平台容器镜像，合并前移除调试标记 将容器镜像固定到多平台索引摘要，而不是特定架构的镜像摘要。从镜像的平台中立发布页面选择摘要，使开发环境和持续集成能够解析到正确的架构。 开发分布式流程时使用结构化的调试线索： - 在状态转换、队列边界和外部调用处添加标记。 - 仅使用已注册的应用程序命名空间；未经批准，不要创建新的命名空间。 - 重现错误之前清除现有跟踪记录。 - 查询时设置限制并使用游标分页。 - 调查期间，将临时标记保留在开发分支上。 - 合并前移除标记和导入。 审查者不应仅仅因为分支中存在已认可的临时检测代码就提出问题。他们应验证这些代码无法进入生产环境，并确认移除步骤是完成流程的一部分。 ## 只运行适合本次更改的检查，并报告省略了什么 移交之前，检查完整的已更改文件集合，并仅运行适用的关卡： - 格式化程序、代码检查修复和只读代码检查。 - 应用程序和私有软件包的类型检查。 - 已发布软件包的实际构建。 - 使用可随时销毁的服务容器进行针对性测试。 - 在正确边界添加软件包更改记录或服务器说明。 - 精确固定共享依赖项的版本。 - 路由发生变化时，测试当前引擎和已停用版本。 - 镜像引用发生变化时，使用多平台镜像摘要。 - SDK或执行行为发生变化时，运行已链接的参考项目。 - 合并前移除临时调试检测代码。 报告运行了什么、哪些项目通过，以及有意省略了哪些关卡和原因。不要用无法观察相关行为的较弱检查来声称运行时、软件包或容器正确。