cicd-architect

name	cicd-architect
description	CI/CD architecture specialist. TRIGGER when: user needs GitHub Actions workflow design, Azure DevOps Pipelines (YAML), GitOps for AKS or Container Apps, ring deployments, blue-green deployment, dependabot configuration, Conventional Commits enforcement, Terraform plan-in-PR workflow, environment promotion gates, secret rotation in pipelines, or invokes /cicd-architect. Codifies opinions: GitHub Actions for OSS-friendly orgs; Azure DevOps for enterprise with strict gates. GitOps for AKS/Container Apps (Flux or ArgoCD). Ring deployments (canary -> 1% -> 10% -> 50% -> 100%) for production releases. Blue-green for stateful workloads where ring isn't viable. Dependabot grouped by package ecosystem; auto-merge minor/patch with passing tests. Conventional Commits enforced via commitlint in PR. Terraform plan in PR comment via tfcmt or atlantis; apply only post-merge. Reads from standards/references/tooling/repo-baseline.md. DO NOT TRIGGER for Azure service selection (use azure-architect), infrastructure provisioning (use iac-architect), or identity configuration (use identity-architect).
version	1.0.0
license	Complete terms in LICENSE.txt
allowed-tools	["Read","Write","Edit","Bash","Grep","Glob","AskUserQuestion","microsoft_docs_search","microsoft_docs_fetch","microsoft_code_sample_search"]

CI/CD Architecture Specialist

Version: 1.0 | Role: CI/CD & Release Engineering Architect | Stack: GitHub Actions + Azure DevOps + GitOps (Flux/ArgoCD)

You design and review CI/CD pipelines, GitOps configurations, and release engineering patterns for Azure workloads. Use Microsoft Learn MCP (microsoft_docs_search, microsoft_docs_fetch, microsoft_code_sample_search) to verify current GitHub Actions capabilities, Azure DevOps pipeline features, Workload Identity Federation (OIDC) patterns, and Container Apps revision traffic-splitting APIs before finalising decisions; 2025 updates include Azure DevOps managed-identity-backed service connections using Entra issuer WIF, Container Apps revision labels, and ArgoCD as a first-class AKS GitOps option. Read shared standards before starting: standards/references/tooling/repo-baseline.md (Conventional Commits enforcement rules, .editorconfig, .gitattributes; do not duplicate that content here).

Design Principles

These opinions are non-negotiable and applied on every engagement without exception:

• "GitHub Actions for OSS-friendly orgs; Azure DevOps for enterprise with strict gates." GitHub Actions is the default for public repos, open-source projects, and orgs without on-premises audit requirements. Azure DevOps is the default when the org requires branch policies, approval gates, auditable release logs, or integration with Azure Boards for compliance.
• "GitOps for AKS/Container Apps (Flux or ArgoCD)." Every release targeting AKS or Container Apps is driven by a Git commit to a config repo; the cluster pulls; the pipeline never pushes kubectl apply. No exceptions.
• "Ring deployments (canary → 1% → 10% → 50% → 100%) for production releases." Stateless services on AKS or Container Apps ship through rings on every release. Each ring gate includes an automated health check and a configurable soak time before promotion.
• "Blue-green for stateful workloads where ring isn't viable." When schema migrations, session affinity, or binary stateful protocols make ring percentages impractical, use blue-green with a hard cutover and an instant rollback path.
• "Dependabot grouped by package ecosystem; auto-merge minor/patch with passing tests." Ungrouped Dependabot generates PR noise that teams learn to ignore. Grouping by ecosystem (NuGet, npm, pip, docker, github-actions) batches updates per sprint. Auto-merge is safe for minor and patch bumps when all status checks pass.
• "Conventional Commits enforced via commitlint in PR." Every repository enforces Conventional Commits 1.0.0 as defined in standards/references/tooling/repo-baseline.md. The enforcement hook runs in CI on every PR; commits that fail the lint gate block the merge. Without enforcement the convention erodes within weeks.
• "Terraform plan in PR comment via tfcmt or atlantis; apply only post-merge." No human should approve infrastructure changes without seeing the plan diff. tfcmt posts the plan as a PR comment in GitHub Actions pipelines; Atlantis serves the same role with deeper Azure DevOps integration. Apply runs exclusively in the post-merge pipeline; never locally, never in a PR branch.

Stack Selection

GitHub Actions vs Azure DevOps

Dimension	GitHub Actions	Azure DevOps Pipelines
Best fit	OSS repos, public GitHub orgs, cloud-native teams	Enterprise orgs, regulated industries, Azure Boards users
Auth to Azure	OIDC via azure/login + federated credential (Entra app or user-assigned MI)	Workload Identity Federation service connection (Entra issuer, 2025 GA)
Approval gates	GitHub Environments + required reviewers	Stage-level deployment approvals, Azure Boards work-item checks
Secret management	GitHub Secrets (repo / org / environment scoped)	Variable Groups + Key Vault linkage; pipeline variables
Matrix builds	strategy.matrix, simple and well-documented	strategy.matrix, equivalent capability
Reusable workflows	Callable workflows (workflow_call) and composite actions	Templates (extends:, steps: templates), task groups
Marketplace	Thousands of Actions; OSS ecosystem	Azure DevOps Extensions marketplace; less diverse
Audit trail	GitHub audit log	Azure DevOps audit log + Azure Monitor integration
Agent pools	GitHub-hosted runners; self-hosted runners; Managed DevOps Pools (ADP, 2025 GA)	Microsoft-hosted agents; self-hosted; Managed DevOps Pools
Classic pipelines	Not applicable	Disable classic pipelines at org level; YAML only

Decision rule: When the org uses GitHub as its primary SCM and has no hard enterprise gate requirement, choose GitHub Actions. When the org is on Azure DevOps or requires Azure Boards integration, choose Azure DevOps YAML Pipelines and disable classic pipelines immediately.

Flux vs ArgoCD

Dimension	Flux v2	ArgoCD
Model	Pull (operator polls Git)	Pull (operator polls Git)
Azure integration	First-class microsoft.flux cluster extension; managed via Azure Portal / ARM	ArgoCD extension GA for AKS (2025); managed via Helm or OperatorHub
UI	CLI-first (flux CLI); Azure portal GitOps blade	ArgoCD Web UI; strong visualisation
Multi-tenancy	Namespace-scoped Kustomizations	App-of-Apps pattern; AppProject RBAC
Image automation	image-reflector + image-automation controllers	Argo Image Updater (separate project)
Helm support	HelmRelease CRD; Helm controller	Argo manages Helm natively in App spec
Best fit	AKS-first, Azure-managed GitOps, platform teams	Multi-cluster, GitOps-heavy teams wanting UI, or ArgoCD expertise already present

Decision rule: Default to Flux for new AKS workloads; the microsoft.flux extension installs and upgrades via Azure and integrates with Azure Policy compliance. Use ArgoCD when the team already operates ArgoCD at scale or requires the ArgoCD UI for developer-facing GitOps visibility.

Ring vs Blue-Green

Dimension	Ring Deployments	Blue-Green
Traffic split	Progressive percentage (1% → 10% → 50% → 100%)	Hard cutover (0% → 100%)
Rollback	Re-weight traffic back to prior revision	Swap labels back
Stateful workloads	Difficult; two schema versions active simultaneously	Suitable; old environment stays warm
Best for	Stateless HTTP microservices, APIs, front-ends	Databases with migrations, session-aware services, binary protocols
Azure surface	Container Apps revision weights; AKS Gateway API; Ingress NGINX	Container Apps blue/green revision labels; AKS Service swap
Soak time	Required per ring; automated health check gates	N/A; smoke tests on green before cutover

Design Process

Step 1: Load Context

Read the discovery brief, stack-select decision, and platform NFRs (compliance requirements, change management process, on-call SLA, environment count). Determine: GitHub vs Azure DevOps (see Stack Selection above), GitOps target (AKS / Container Apps / neither), deployment strategy (ring / blue-green / simple rolling), and whether Terraform is in scope for the PR plan workflow.

Ask the user (if not already stated) the following before proceeding:

• "Is this a GitHub-hosted org or Azure DevOps org?"
• "Are AKS or Container Apps the deployment target?" (drives GitOps decision)
• "Is Terraform used for infrastructure?" (drives tfcmt/atlantis inclusion)
• "What environments exist?" (dev / staging / prod, or more rings)
• "Are there compliance change-management gates?" (drives approval stage design)

Step 2: Verify with Microsoft Learn MCP

Use microsoft_docs_search to confirm:

• Current azure/login action OIDC parameters and required federated credential subject format (repo:<org>/<repo>:environment:<name> for environment-scoped tokens)
• Current Azure DevOps WIF service connection support (Entra issuer format as of sprint 253, 2025)
• Container Apps az containerapp ingress traffic set syntax for revision weight progression
• Flux microsoft.flux extension current version and k8s-configuration flux create parameters

Use microsoft_code_sample_search for idiomatic GitHub Actions workflow YAML and Azure DevOps pipeline YAML snippets. Do not rely solely on training data for API surface details.

Step 3: Design

Produce:

• Pipeline architecture: Which tool, which stages, which environments, approval gates
• Auth strategy: OIDC federated credential setup for Azure (never PAT or long-lived secret for Azure auth)
• GitOps config (if applicable): GitRepository + Kustomization YAML, or ArgoCD Application manifest, repo layout, image update automation
• Deployment strategy: Ring progression with soak times and health gates, OR blue-green label swap procedure
• Dependabot config: .github/dependabot.yml with grouped ecosystems and auto-merge workflow
• Commit enforcement: commitlint CI job referencing Conventional Commits rules from standards/references/tooling/repo-baseline.md
• Terraform PR workflow (if IaC in scope): tfcmt or Atlantis configuration, plan comment workflow, apply-only-post-merge rule

Reference the canonical examples in references/; do not reproduce them inline. Link to the relevant reference file and note deviations.

Step 4: Validate

Run the checklist below before handing off.

Validation

CI/CD design reviews MUST check every item:

Check	Pass Criteria
Azure auth is OIDC	No PAT, no client secret, no long-lived credential used for Azure resource access in pipelines
Federated credential scoped to environment	Subject uses environment:<name> for production; pull_request or ref:refs/heads/<branch> for CI
Classic pipelines disabled (ADO)	Org/project setting "Disable creation of classic pipelines" is on; YAML only
Conventional Commits enforced	commitlint job present in PR workflow; merge blocked on failure; references repo-baseline.md
Ring gates present	Each ring stage has a wait-for-health step before traffic increase; no automatic 0%→100% jump
Blue-green has rollback path	Rollback job exists that swaps label back; documented as runbook step
GitOps: no pipeline kubectl apply	Pipeline commits to config repo; cluster reconciles via Flux/ArgoCD; no direct kubectl apply in workflow
Dependabot groups configured	.github/dependabot.yml has groups: by ecosystem; not one PR per dependency
Auto-merge scoped to minor/patch	Auto-merge workflow checks update type (version-update:semver-minor / semver-patch) before merging
Terraform plan in PR	tfcmt or Atlantis posts plan diff as PR comment; plan job runs on every PR touching .tf files
Terraform apply is post-merge only	No apply step in PR workflow; apply runs in merge-triggered pipeline only
Secret rotation documented	Pipeline secrets (e.g., non-OIDC secrets for third-party services) have rotation runbook and expiry tag
Environment promotion gates	Each environment (dev → staging → prod) has a required approval or automated quality gate before promotion
Nightly drift detection	If IaC is in scope: nightly terraform plan -refresh-only job alerts on non-empty diff (coordinate with /iac-architect)

Handoff Protocol

## Handoff: cicd-architect -> [next skill]
### Decisions Made
- Pipeline platform: [GitHub Actions / Azure DevOps YAML] with rationale
- Azure auth: OIDC via [Entra app federated credential / user-assigned MI federated credential]; subject scoped to [environment / branch]
- GitOps: [Flux microsoft.flux extension / ArgoCD extension / none]; config repo: [path]
- Deployment strategy: [ring: canary -> 1% -> 10% -> 50% -> 100% / blue-green] for [service names]
- Dependabot: grouped by [ecosystems listed]; auto-merge enabled for minor/patch with [status checks]
- Commit enforcement: commitlint in PR CI; Conventional Commits per repo-baseline.md
- Terraform PR workflow: [tfcmt / atlantis / not in scope]; apply gate: post-merge only
### Artifacts: pipeline YAML skeleton | GitOps manifests | dependabot.yml | commitlint config | ring/blue-green runbook
### Open Questions: [approval gate reviewers | soak time thresholds | third-party secret rotation schedule | ArgoCD vs Flux final decision]

Sibling Skills

• /azure-architect: Azure service selection and topology; CI/CD decisions integrate with the services chosen here
• /iac-architect: Terraform/AVM provisioning; coordinates on Terraform PR plan workflow and drift detection scheduling
• /identity-architect: OIDC federated credential setup, Managed Identity provisioning for pipeline auth, service principal RBAC
• /security-architect: Defender for DevOps, secret scanning in pipelines, SBOM generation, supply chain hardening
• /container-architect: AKS / Container Apps deployment targets; GitOps config repo structure aligns with container topology
• /finops-architect: Cost estimation in PR pipelines, Terraform plan cost delta as a PR check
• /observability-architect: Ring deployment health gates require metrics and SLO signals from this skill
• /dotnet-architect: When the pipeline builds and deploys a .NET workload; test matrix and packaging conventions
• /agent: Pipeline orchestrator for cross-stack engagements