DevOps Workflow Engineer

Generate GitHub Actions workflow YAML, analyze existing pipelines for optimization opportunities, and create deployment plans with strategy selection, health checks, and rollback procedures.

Core Capabilities

• CI pipeline design — fail-fast job ordering (lint → unit → build → integration → security) with matrix testing and CI time/flake/cache targets.
• CD & multi-environment — dev/staging/prod promotion flows, build-once-deploy-everywhere, environment protection rules, and rollback at every stage.
• Pipeline optimization — detect missing caching, missing timeouts, serial chains, deprecated actions, leaked secrets, and oversized runners; apply path filtering and concurrency cancellation.
• Deployment strategies — choose blue-green, canary, or rolling via decision tree; canary traffic-split schedule with promotion gates.
• GitHub Actions patterns — reusable workflows, OIDC auth, secrets hierarchy, and runner cost estimation.

When to Use

• Designing a new CI or CD workflow from scratch.
• Planning a multi-environment (dev/staging/prod) deployment.
• Optimizing an existing pipeline's cost or runtime.
• Implementing a blue-green, canary, or rolling deployment strategy.

Clarify First

Before generating the workflow, settle the inputs below. When one is missing or vague and would change the result, ask about it; when it wouldn't, use a sensible default and say which one you used.

• Workflow type: CI, CD, release, or security-scan (sets workflow_generator.py --type).
• Stack: language and test framework (e.g. python/pytest) (drives the generated YAML steps via --language/--test-framework).
• Deployment strategy & environments: blue-green, canary, or rolling, and which of dev/staging/prod (drives the deployment_planner.py plan).

Ask about the two or three inputs that matter most for this request, not the whole list. If the user wants a result straight away, produce it and state your assumptions at the top.

Workflow

1. Decide what CI is for. Many teams run the test suite locally before pushing and let CI only lint, build and deploy; others gate merges on CI tests. Ask, and generate with --no-tests for the first case.
2. Generate the workflow with workflow_generator.py (CI, CD, release, security-scan or docs-check) and adapt the install, lint and deploy commands to the repository.
3. Harden it: least-privilege permissions:, OIDC instead of long-lived cloud keys, timeout-minutes on every job, concurrency cancellation, and third-party actions pinned to a full commit SHA (tools such as Dependabot or pinact keep SHA pins current). The generator emits major-version tags (for example actions/checkout@v7) for readability; in production, pin each one to its full commit SHA with the tag as a comment.
4. Analyze the result and any existing workflows with pipeline_analyzer.py; fix every critical finding.
5. Plan the rollout with deployment_planner.py (blue-green, canary or rolling) and wire its health checks and rollback steps into the CD job.
6. Verify on a branch: the workflow runs green, a deliberately failing step fails the run, and a rollback has been rehearsed.

Quick Start

python3 scripts/workflow_generator.py --type ci --language python --test-framework pytest
python3 scripts/workflow_generator.py --type ci --language node --no-tests --branches main
python3 scripts/pipeline_analyzer.py assets/sample_flawed_workflow.yml       # hard-coded key, v2 actions, no timeouts (exit 1)
python3 scripts/pipeline_analyzer.py assets/ci-template.yml                  # info only (exit 0)
python3 scripts/deployment_planner.py --type webapp --environments dev,staging,prod --strategy canary

Tools Overview

Generated versions as of November 2026: Python 3.11-3.15 (default 3.14), Node 22, 24 and 26 LTS (default 24), Go oldstable/stable aliases, Rust stable/beta; GitHub actions checkout@v7, setup-python@v7, setup-node@v7, setup-go@v7, cache@v6, upload-artifact@v7, download-artifact@v8. Check them against current support schedules and releases before relying on them.

Anti-Patterns

Mistake: Pinning actions to a tag such as @v7 in production.
Why it happens: Tags read well and update automatically.
Instead: Tags can be moved to malicious commits. Pin to a full SHA with a comment naming the version, and let a bot bump it.

Mistake: Storing cloud credentials as repository secrets for deploys.
Why it happens: It is the quickest way to get a deploy working.
Instead: Use OIDC federation to the cloud provider with a role scoped to the environment.

Mistake: Running the full suite in CI when the team already runs it locally, and calling the duplicate "safety".
Why it happens: CI templates include a test job by default.
Instead: Decide where tests run. If locally, generate --no-tests and keep CI for lint, build, deploy and environment-only checks such as migration rehearsal.

Files

• scripts/workflow_generator.py, scripts/pipeline_analyzer.py, scripts/deployment_planner.py — the tools above.
• assets/ci-template.yml, assets/cd-template.yml — reference workflows; assets/sample_flawed_workflow.yml — analyzer demo with a fake placeholder key.

Reference Documentation

Load the reference that matches the task — keep this file lean and pull detail on demand:

• references/workflows-and-optimization.md — the CI / CD / optimization workflows with full YAML, deployment-strategy decision tree and canary schedule, GitHub Actions patterns, runner cost table, anti-patterns, and troubleshooting. Read when building or tuning a pipeline.
• references/github-actions-patterns.md — deep GitHub Actions pattern library. Read when authoring advanced workflow YAML.
• references/deployment-strategies.md — deep deployment strategy guide (blue-green, canary, rolling). Read when planning a release rollout.
• references/agentic-workflows-guide.md — agentic/automated workflow patterns. Read when wiring up AI-driven or autonomous pipeline steps.

Scope & Limitations

In Scope:

• Generating GitHub Actions YAML with workflow_generator.py for CI, CD, release, security-scan and docs-check workflows in Python, Node, Go or Rust, with CD targets for Kubernetes, Docker Compose, AWS ECS or static hosting
• Analyzing existing workflow files with pipeline_analyzer.py for missing caching and timeouts, serial job chains, deprecated actions, possible leaked secrets and oversized runners, with severity ratings and cost estimates
• Deployment plans from deployment_planner.py for blue-green, canary or rolling releases, with health checks and rollback steps per environment
• Patterns for reusable workflows, OIDC authentication, secrets hierarchy and multi-environment promotion from the references

Out of Scope:

• CI systems other than GitHub Actions, such as GitLab CI, CircleCI and Buildkite (see engineering/ci-cd-pipeline-builder/)
• Provisioning infrastructure (see engineering/terraform-patterns/ and engineering/senior-devops/)
• Versioning, changelogs and release coordination (see engineering/release-orchestrator/)
• Helm chart authoring and review (see engineering/helm-chart-builder/)
• Running deployments or watching live rollouts; the tools produce files and plans only

Important Caveats:

• Generated workflows are templates. Secrets, environment names, deploy commands and action versions need review before the workflow runs.
• The analyzer parses YAML with a minimal built-in parser and pattern checks. Complex anchors, expressions and reusable-workflow calls can be misread, and it does not run the workflow.
• Runner cost estimates use a fixed per-minute table for GitHub-hosted runners. GitHub pricing and runner images change, so treat the numbers as rough.
• Action versions and deprecations go stale quickly. Check pinned actions against their current releases.

Integration Points