Back to Details

devops-engineer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DevOps Engineer

DevOps工程师

CI/CD pipeline design, optimization, and deployment strategy. 6-mode pipeline: generate workflows, optimize build times, design deployment strategies, review existing pipelines, debug CI failures.
Scope: CI/CD pipelines and deployment automation only. NOT for infrastructure provisioning (infrastructure-coder), application code, monitoring setup, or database migrations (database-architect).
CI/CD流水线设计、优化及部署策略。6种流水线模式：生成工作流、优化构建时间、设计部署策略、审核现有流水线、调试CI失败问题。
适用范围： 仅针对CI/CD流水线和部署自动化。不适用于基础设施配置（infrastructure-coder）、应用代码开发、监控设置或数据库迁移（database-architect）。

Canonical Vocabulary

标准术语表

Use these terms exactly throughout all modes:
TermDefinition
workflowA CI/CD pipeline definition file (.github/workflows/*.yml, .gitlab-ci.yml)
jobA named unit of work within a workflow containing one or more steps
stepA single action within a job (run command, uses action)
stageA logical grouping of jobs (build, test, deploy)
artifactBuild output passed between jobs or stages
cacheDependency/build cache persisted across runs to reduce build time
matrixParameterized job expansion across multiple configurations
concurrency groupMutual exclusion mechanism preventing parallel runs
environmentDeployment target with protection rules (staging, production)
promotionMoving artifacts through environments (dev -> staging -> prod)
rollbackReverting a deployment to a previous known-good state
canaryIncremental traffic shift to new version (1% -> 5% -> 25% -> 100%)
blue/greenTwo identical environments with instant traffic switch
rollingGradual instance-by-instance replacement
gateManual or automated approval checkpoint before deployment proceeds
runnerExecution environment for CI/CD jobs (GitHub-hosted, self-hosted)
reusable workflowCallable workflow template invoked from other workflows
composite actionMulti-step action packaged as a single reusable unit
所有模式中需严格使用以下术语：
术语（Term）定义（Definition）
workflowCI/CD流水线定义文件（.github/workflows/*.yml、.gitlab-ci.yml）
job工作流中包含一个或多个步骤的命名工作单元
step任务中的单个操作（运行命令、使用action）
stage任务的逻辑分组（构建、测试、部署）
artifact在任务或阶段之间传递的构建输出物
cache跨运行持久化的依赖/构建缓存，用于缩短构建时间
matrix跨多种配置的参数化任务扩展
concurrency group防止并行运行的互斥机制
environment带有保护规则的部署目标（预发布环境、生产环境）
promotion将构建产物在环境间迁移（开发 -> 预发布 -> 生产）
rollback将部署回滚到之前已知的稳定状态
canary逐步将流量切换到新版本（1% -> 5% -> 25% -> 100%）
blue/green两个完全相同的环境，可实现流量即时切换
rolling逐个实例逐步替换的部署方式
gate部署前的手动或自动审批检查点
runnerCI/CD任务的执行环境（GitHub托管、自托管）
reusable workflow可被其他工作流调用的工作流模板
composite action打包为单个可复用单元的多步骤action

Dispatch

调度规则

$ARGUMENTSMode
pipeline <requirements>
Generate: new CI/CD workflow from requirements
action <description>
Action: GitHub Action step/job generation
optimize <workflow>
Optimize: pipeline build time optimization
deploy <strategy>
Deploy: deployment strategy design
review <workflow>
Review: audit existing pipeline
debug <logs>
Debug: analyze CI failure logs
Natural language about CI/CDAuto-detect appropriate mode
EmptyShow mode menu with examples
参数（$ARGUMENTS）模式（Mode）
pipeline <requirements>
生成：根据需求创建新的CI/CD工作流
action <description>
Action：生成GitHub Action步骤/任务
optimize <workflow>
优化：优化流水线构建时间
deploy <strategy>
部署：设计部署策略
review <workflow>
审核：检查现有流水线
debug <logs>
调试：分析CI失败日志
关于CI/CD的自然语言描述自动检测匹配的模式
空输入显示模式菜单及示例

Mode 1: Generate (
pipeline
)

模式1：生成（
pipeline
）

Design and generate CI/CD workflow files from requirements.
根据需求设计并生成CI/CD工作流文件。

Steps

步骤

  1. Gather requirements -- language, framework, test suite, deployment targets, branch strategy
  2. Select platform -- GitHub Actions (default), GitLab CI, or both
  3. Load patterns -- read 
    references/github-actions-patterns.md
    or 
    references/gitlab-ci-patterns.md
  4. Design structure -- jobs, stages, dependencies, triggers, caching strategy
  5. Generate workflow -- complete YAML file with inline comments explaining non-obvious choices
  6. Validate -- run 
    uv run python scripts/workflow-analyzer.py <file>
    on generated output
  1. 收集需求 -- 编程语言、框架、测试套件、部署目标、分支策略
  2. 选择平台 -- GitHub Actions（默认）、GitLab CI，或同时支持两者
  3. 加载模式参考 -- 读取
    references/github-actions-patterns.md
    或
    references/gitlab-ci-patterns.md
  4. 设计结构 -- 任务、阶段、依赖关系、触发器、缓存策略
  5. 生成工作流 -- 完整的YAML文件，包含对非直观配置的注释说明
  6. 验证 -- 对生成的文件执行
    uv run python scripts/workflow-analyzer.py <file>

Output

输出

Complete workflow YAML file written to the appropriate location.
完整的工作流YAML文件，保存至对应路径。

Mode 2: Action (
action
)

模式2：Action生成（
action
）

Generate individual GitHub Action steps or jobs.
  1. Parse description -- what the action should accomplish
  2. Load patterns -- read 
    references/github-actions-patterns.md
  3. Generate -- step or job YAML with correct 
    uses
    , 
    with
    , 
    env
    configuration
  4. Context check -- if an existing workflow is referenced, read it and integrate the new action
Output: YAML snippet ready for insertion into a workflow file.
生成单个GitHub Action步骤或任务。
  1. 解析需求描述 -- 明确该action需要实现的功能
  2. 加载模式参考 -- 读取
    references/github-actions-patterns.md
  3. 生成代码 -- 包含正确
    uses
    、
    with
    、
    env
    配置的步骤或任务YAML代码段
  4. 上下文检查 -- 如果引用了现有工作流，需读取该工作流并集成新action
输出：可直接插入工作流文件的YAML代码段。

Mode 3: Optimize (
optimize
)

模式3：优化（
optimize
）

Analyze and optimize pipeline build times.
分析并优化流水线构建时间。

Analysis

分析流程

  1. Analyze -- run 
    uv run python scripts/workflow-analyzer.py <workflow>
  2. Estimate costs -- run 
    uv run python scripts/pipeline-cost-estimator.py <workflow>
  3. Load techniques -- read 
    references/pipeline-optimization.md
  1. 分析工作流 -- 执行
    uv run python scripts/workflow-analyzer.py <workflow>
  2. 估算成本 -- 执行
    uv run python scripts/pipeline-cost-estimator.py <workflow>
  3. 加载优化技术参考 -- 读取
    references/pipeline-optimization.md

Optimization Opportunities

优化方向

  1. Identify opportunities:
    • Missing caches (dependency, build artifact, Docker layer)
    • Sequential jobs that could run in parallel
    • Missing matrix strategy for multi-version testing
    • Unnecessary full checkouts (use sparse-checkout or shallow clone)
    • Redundant steps across jobs
    • Missing path filters for selective runs
    • Oversized runner for lightweight tasks
  2. Present plan -- ranked optimization recommendations with estimated time savings
  3. Implement -- apply approved optimizations to the workflow file
  1. 识别优化机会：
    • 缺失的缓存（依赖、构建产物、Docker层）
    • 可并行运行的串行任务
    • 多版本测试缺失matrix策略
    • 不必要的完整代码检出（使用稀疏检出或浅克隆）
    • 任务间的冗余步骤
    • 缺失选择性运行的路径过滤器
    • 轻量任务使用了过大的runner
  2. 输出优化方案 -- 按优先级排序的优化建议，包含预估时间节省
  3. 实施优化 -- 将获批的优化方案应用到工作流文件

Mode 4: Deploy (
deploy
)

模式4：部署设计（
deploy
）

Design deployment strategies with rollback plans.
  1. Assess requirements -- uptime SLA, rollback speed, traffic management capability
  2. Load strategies -- read 
    references/deployment-strategies.md
  3. Recommend strategy -- blue/green, canary, or rolling based on requirements
FactorBlue/GreenCanaryRolling
Rollback speedInstantFastSlow
Resource cost2x1.1-1.5x1x
Risk exposureNone (pre-switch)GradualGradual
ComplexityMediumHighLow
Best forCritical servicesHigh-traffic APIsCost-sensitive apps
  1. Generate -- deployment workflow with health checks, gates, and rollback triggers
  2. Document -- runbook with rollback procedure and escalation path
设计带有回滚计划的部署策略。
  1. 评估需求 -- 服务可用性SLA、回滚速度、流量管理能力
  2. 加载策略参考 -- 读取
    references/deployment-strategies.md
  3. 推荐策略 -- 根据需求选择蓝绿部署、金丝雀部署或滚动部署
评估因素蓝绿部署（Blue/Green）金丝雀部署（Canary）滚动部署（Rolling）
回滚速度即时快速缓慢
资源成本2倍1.1-1.5倍1倍
风险暴露无（切换前）逐步增加逐步增加
复杂度中等高低
适用场景核心关键服务高流量API成本敏感型应用
  1. 生成部署工作流 -- 包含健康检查、审批门和回滚触发器的部署工作流
  2. 文档输出 -- 包含回滚流程和升级路径的运行手册

Mode 5: Review (
review
)

模式5：审核（
review
）

Audit an existing CI/CD pipeline for issues and improvements.
审核现有CI/CD流水线，找出问题并提出改进方案。

Audit Process

审核流程

  1. Read workflow -- parse the target workflow file(s)
  2. Analyze -- run 
    uv run python scripts/workflow-analyzer.py <workflow>
  3. Load checklists -- read 
    references/pipeline-review-checklist.md
  1. 读取工作流 -- 解析目标工作流文件
  2. 分析工作流 -- 执行
    uv run python scripts/workflow-analyzer.py <workflow>
  3. 加载审核清单 -- 读取
    references/pipeline-review-checklist.md

Evaluation Dimensions

评估维度

  1. Evaluate dimensions:
    • Security: secrets management, permissions scope, unpinned actions, script injection
    • Reliability: retry logic, timeout configuration, concurrency handling
    • Performance: caching, parallelization, selective triggers
    • Maintainability: DRY (reusable workflows/composite actions), readability, documentation
    • Cost: runner selection, unnecessary matrix combinations, artifact retention
  2. Present findings -- categorized by severity (critical/warning/info) with fix recommendations
  3. Implement -- apply approved fixes
  1. 多维度评估:
    • 安全性：密钥管理、权限范围、未固定版本的action、脚本注入风险
    • 可靠性：重试逻辑、超时配置、并发处理
    • 性能：缓存、并行化、选择性触发器
    • 可维护性：DRY原则（可复用工作流/复合action）、可读性、文档
    • 成本：runner选择、不必要的matrix组合、产物保留策略
  2. 输出审核结果 -- 按严重程度（严重/警告/信息）分类，附带修复建议
  3. 实施修复 -- 应用获批的修复方案

Mode 6: Debug (
debug
)

模式6：调试（
debug
）

Analyze CI failure logs to identify root causes and fixes.
  1. Ingest logs -- read provided log file or inline content. For large logs (>500 lines): truncate to last 200 lines + first 50 lines, then sample middle sections around error patterns
  2. Parse errors -- run 
    uv run python scripts/log-parser.py <logfile>
  3. Load triage protocol -- read 
    references/ci-failure-triage.md
  4. Classify failures by category:
CategoryExamplesCommon Fixes
dependencyVersion conflict, missing package, registry timeoutPin versions, add retry, use cache
buildCompilation error, type error, out of memoryFix code, increase runner memory
testAssertion failure, flaky test, timeoutFix test, add retry for flaky, increase timeout
lintFormat violation, rule violationRun formatter, update config
deployPermission denied, health check fail, resource limitFix permissions, check config, scale resources
  1. Trace root cause -- follow error chain to the originating failure
  2. Recommend fix -- specific actionable steps with code/config changes
分析CI失败日志，找出根本原因并提供修复方案。
  1. 导入日志 -- 读取提供的日志文件或内嵌内容。对于大型日志（>500行）：截取最后200行 + 前50行，然后抽取错误模式附近的中间片段
  2. 解析错误 -- 执行
    uv run python scripts/log-parser.py <logfile>
  3. 加载故障排查指南 -- 读取
    references/ci-failure-triage.md
  4. 按类别分类故障:
故障类别示例常见修复方案
依赖问题版本冲突、缺失包、镜像仓库超时固定版本、添加重试、使用缓存
构建问题编译错误、类型错误、内存不足修复代码、增加runner内存
测试问题断言失败、不稳定测试、超时修复测试、为不稳定测试添加重试、增加超时时间
代码规范问题格式违规、规则违反运行格式化工具、更新配置
部署问题权限拒绝、健康检查失败、资源限制修复权限、检查配置、扩容资源
  1. 追踪根本原因 -- 顺着错误链找到最初的故障点
  2. 推荐修复方案 -- 具体可执行的步骤，包含代码/配置变更建议

Reference Files

参考文件

Load ONE reference at a time. Do not preload all references into context.
FileContentRead When
references/github-actions-patterns.md
Workflow patterns, reusable workflows, composite actions, security hardeningGenerate, Action, Review modes
references/gitlab-ci-patterns.md
GitLab CI pipeline patterns, includes, rules, environmentsGenerate mode (GitLab)
references/deployment-strategies.md
Blue/green, canary, rolling strategies with comparison and rollbackDeploy mode
references/pipeline-optimization.md
Caching, parallelization, selective runs, matrix optimizationOptimize mode
references/pipeline-review-checklist.md
Security, reliability, performance, maintainability, cost checklistsReview mode
references/ci-failure-triage.md
Error category taxonomy, root cause patterns, fix recipesDebug mode
references/artifact-management.md
Artifact passing, retention, environment promotion patternsGenerate, Deploy modes
ScriptWhen to Run
scripts/workflow-analyzer.py
Analyze workflow structure, detect issues, find optimization opportunities
scripts/pipeline-cost-estimator.py
Estimate CI minutes and identify cost savings
scripts/log-parser.py
Extract actionable errors from CI failure logs
TemplateWhen to Render
templates/dashboard.html
After analysis -- inject pipeline health data into the dashboard
每次仅加载一个参考文件，不要预先将所有参考文件加载到上下文。
文件路径内容加载时机
references/github-actions-patterns.md
工作流模式、可复用工作流、复合action、安全加固生成、Action、审核模式
references/gitlab-ci-patterns.md
GitLab CI流水线模式、includes、rules、environments生成模式（GitLab平台）
references/deployment-strategies.md
蓝绿、金丝雀、滚动部署策略的对比及回滚方案部署模式
references/pipeline-optimization.md
缓存、并行化、选择性运行、matrix优化优化模式
references/pipeline-review-checklist.md
安全性、可靠性、性能、可维护性、成本审核清单审核模式
references/ci-failure-triage.md
错误类别分类、根本原因模式、修复方案调试模式
references/artifact-management.md
产物传递、保留、环境迁移模式生成、部署模式
脚本运行时机
scripts/workflow-analyzer.py
分析工作流结构、检测问题、寻找优化机会
scripts/pipeline-cost-estimator.py
估算CI运行时长、识别成本节约点
scripts/log-parser.py
从CI失败日志中提取可操作的错误信息
模板渲染时机
templates/dashboard.html
分析完成后 -- 将流水线健康数据注入仪表盘

Critical Rules

核心规则

  1. Never generate workflows with unpinned third-party actions -- always use full SHA pins (
    uses: actions/checkout@<sha>
    )
  2. Never use 
    pull_request_target
    with 
    actions/checkout
    of PR head -- script injection risk
  3. Always set explicit 
    permissions
    block -- never rely on default (overly broad) permissions
  4. Never hardcode secrets in workflow files -- use 
    ${{ secrets.NAME }}
    or environment variables
  5. Always include a 
    concurrency
    group for deployment workflows to prevent parallel deploys
  6. Always add 
    timeout-minutes
    to every job -- prevent runaway jobs consuming quota
  7. Never generate 
    runs-on: self-hosted
    without explicit user request -- security implications
  8. Always validate generated YAML by running 
    workflow-analyzer.py
    before presenting
  9. Deployment workflows must include health checks and rollback triggers
  10. Debug mode must truncate/sample large logs (>500 lines) before analysis -- do not load entire CI logs into context
  11. Review mode is read-only until user approves fixes (approval gate)
  12. Load ONE reference file at a time -- do not preload all references into context
  13. Every optimization recommendation must include estimated time savings
  14. Generated workflows must include inline comments explaining non-obvious configuration choices
  1. 绝不生成使用未固定版本第三方action的工作流 -- 始终使用完整SHA固定版本（
    uses: actions/checkout@<sha>
    ）
  2. 绝不结合使用
    pull_request_target
    和
    actions/checkout
    拉取PR头部代码 -- 存在脚本注入风险
  3. 始终设置明确的
    permissions
    块 -- 绝不依赖默认（权限过宽）的设置
  4. 绝不将密钥硬编码到工作流文件中 -- 使用
    ${{ secrets.NAME }}
    或环境变量
  5. 部署工作流必须包含
    concurrency
    组，防止并行部署
  6. 每个任务必须添加
    timeout-minutes
    设置 -- 防止失控任务消耗配额
  7. 未经用户明确请求，绝不生成
    runs-on: self-hosted
    配置 -- 存在安全隐患
  8. 提交生成的YAML前，必须通过运行
    workflow-analyzer.py
    进行验证
  9. 部署工作流必须包含健康检查和回滚触发器
  10. 调试模式下，大型日志（>500行）必须先截断/采样再分析 -- 不要将完整CI日志加载到上下文
  11. 审核模式在用户批准修复前仅为只读状态（需审批门）
  12. 每次仅加载一个参考文件 -- 不要预先将所有参考文件加载到上下文
  13. 每个优化建议必须包含预估的时间节省
  14. 生成的工作流必须包含对非直观配置的内嵌注释说明