Back to Details

ci-cd-and-automation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CI/CD and Automation

CI/CD与自动化

Use this skill when

使用此Skill的场景

Use this Skill when adding or changing automated checks, build pipelines, release workflows, deployment verification, or failure handling.
Do not invent provider-specific configuration without repository evidence. Keep project-specific commands in project rules or pipeline files.
当你需要添加或修改自动化检查、构建流水线、发布工作流、部署验证或故障处理流程时，使用本Skill。
请勿在没有仓库证据的情况下凭空创建特定服务商的配置。将项目专属命令保留在项目规则或流水线文件中。

Quality-gate sequence

质量门流程

  1. Define the behavior or artifact the pipeline must protect.
  2. Identify the cheapest reliable check for each failure class.
  3. Run fast feedback first, then slower integration or release checks.
  4. Preserve actionable logs and artifacts on failure.
  5. Verify the built artifact and deployment target, not only the source checkout.
  6. Define stop, retry, rollback, or manual intervention conditions.
  7. Keep the pipeline proportional to the risk.
  1. 定义流水线必须保护的行为或工件。
  2. 为每类故障确定成本最低且可靠的检查方式。
  3. 先运行快速反馈检查，再执行较慢的集成或发布检查。
  4. 故障发生时保留可用于排查的日志和工件。
  5. 验证流水线生成的工件和部署目标，而不仅仅是源码检出结果。
  6. 定义终止、重试、回滚或人工干预的条件。
  7. 使流水线的复杂度与风险相匹配。

MUST

必须遵守的规则

  • Keep required checks deterministic enough to diagnose.
  • Fail when a required quality gate fails.
  • Preserve evidence that explains a failed job.
  • Verify the artifact produced by the pipeline.
  • Define what happens after a failed deployment or health check.
  • Keep secrets and environment-specific policy out of general Skill instructions.
  • 确保必要检查具有足够的确定性，以便排查问题。
  • 当必要的质量门检查失败时，流水线必须终止。
  • 保留能解释作业失败原因的证据。
  • 验证流水线生成的工件。
  • 定义部署失败或健康检查不通过后的处理流程。
  • 不要在通用Skill说明中包含密钥和环境专属策略。

SHOULD

建议遵守的规则

  • Run fast unit and static checks before slower integration checks.
  • Cache only when cache invalidation cannot hide failures.
  • Separate build, test, package, deploy, and post-deploy verification responsibilities.
  • Make flaky checks visible and track their removal.
  • Prefer a reversible rollout when the failure cost is high.
  • 在较慢的集成检查之前，先运行快速的单元测试和静态检查。
  • 仅当缓存失效不会掩盖故障时才使用缓存。
  • 将构建、测试、打包、部署和部署后验证的职责分离。
  • 让不稳定的检查可见，并跟踪其修复情况。
  • 当故障成本较高时，优先选择可回滚的发布方式。

Do not

禁止操作

  • treat a green pipeline as proof of all business correctness;
  • add a quality gate that nobody can diagnose;
  • hide failures through retries without measuring the underlying cause;
  • deploy an artifact different from the one verified;
  • encode a project-specific provider assumption as a global rule.
Read quality-gates.md for check design and release-verification.md for artifact and deployment verification.
  • 不要将显示正常的流水线视为业务完全正确的证明；
  • 不要添加无人能排查的质量门；
  • 不要在未排查根本原因的情况下通过重试掩盖故障；
  • 不要部署与已验证版本不同的工件；
  • 不要将项目专属的服务商假设编码为全局规则。
阅读quality-gates.md了解检查设计相关内容，阅读release-verification.md了解工件和部署验证相关内容。

Routing

路由指引

Use code-review-and-quality to inspect pipeline changes. Use git-workflow-and-versioning for release history. Use systematic-debugging for failed jobs or deployments.
使用code-review-and-quality技能检查流水线变更。使用git-workflow-and-versioning技能处理发布历史。使用systematic-debugging技能排查失败的作业或部署问题。

Verification

验证标准

A pipeline change is complete when the required checks, failure evidence, artifact identity, deployment verification, and rollback or stop conditions are demonstrably defined.
当必要检查、故障证据、工件标识、部署验证以及回滚或终止条件都已明确定义并可验证时，流水线变更才算完成。