主题： continuous-integration
-
设计持续集成流水线
CI 流水线应快速、能够自我测试，并对每项变更采用同一流程：从干净检出的代码构建，分阶段运行静态检查和测试，明确暴露失败，并让总耗时足够短，使人愿意等待结果。
-
Keeping CI and local checks identical: one entry point, pinned tools, same container
A check that passes locally should pass in CI and vice versa: define every check once as a named task, pin the toolchain in a committed manifest that both the bootstrap and the pipeline install from, run CI in the same container image as the dev environment, fix locale and timezone, and treat any CI-only failure as a parity bug to eliminate before fixing the symptom.
-
使用容器中的临时数据库进行集成测试
每次测试运行都在一次性容器中启动真实数据库引擎，将数据保存在内存中，只对模板数据库执行一次迁移，再为每个测试文件复制模板。这样测试检查的就是真实的规划器、约束和隔离行为，而不是内存替代品。
-
用图遍历确定依赖顺序：BFS、DFS 与拓扑排序
将依赖建模为有向图，用广度优先或深度优先遍历找到变更影响的所有项，再用 Kahn 算法或 DFS 后序遍历生成构建或迁移顺序，并显式报告环，而不是隐藏它；graphlib 和 tsort 提供这种排序。
-
开展变异测试，避免被存活变异体淹没
先在一个模块上运行变异工具，将每个存活变异体归类为缺失断言、缺失场景或等价变异体；修复前两类，排除第三类，通过增量运行或仅检查差异限制耗时。按模块将分数作为只升不降的基线，而不是全局目标。
-
Automated game tests: combine headless checks with rendering evidence
Design a practical game test suite with isolated logic tests, reproducible scene checks and controlled screenshot comparisons, including clear failure and baseline policies.
-
Which pre-deployment checks have actually stopped a bad release in the last year, and which have never fired?
Open question: pipelines accumulate gates (tests, scans, smoke checks, canary analysis, manual approvals, rollout deadlines), and the Kubernetes documentation notes that a stalled Deployment is only reported, not rolled back; which gates have a record of stopping a bad release, which never fired, and which fired only falsely?
-
Consumer-driven contract tests: verifying integrations without a shared environment
A consumer-driven contract records the requests a consumer makes and the minimal response it relies on; the consumer tests against a mock built from that record, and the provider replays it against its real code. Both sides run in their own pipelines, and a version matrix answers whether a release is compatible with what is deployed.
-
构建来源证明：SLSA 记录什么，以及如何验证
SLSA 的 Build 方向评定制品来源信息的可信程度，从“存在来源信息”（L1）到加固的构建平台（L3）。来源信息是一份 in-toto 证明，列出制品摘要、构建者、构建类型及其外部参数；使用前，消费方依据信任根和预期值进行验证。
-
按分支创建预览环境：每个拉取请求一份部署副本，合并时销毁
为每个拉取请求提供独立 URL 下运行的应用副本：每次提交只构建一次，按拉取请求编号命名，使用本地种子数据填充，并连接第三方沙箱。将 URL 发回拉取请求，限制并发数量，在合并、关闭或长期无活动时删除副本及其数据。
-
主干开发与短期分支
至少每天将所有人的工作集成到一条共享主线，保持分支短暂存在，并用标志隐藏未完成的工作，可以减少合并冲突，让持续集成真正落地。
-
Git hooks for fast local checks
Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.
-
诊断并消除不稳定测试
不稳定测试会在代码未改变时有时通过、有时失败；常见原因是共享状态、对时序的假设、顺序依赖和真实的外部服务。先隔离，再复现并修复原因，绝不能只靠重试。
机器可读： JSON