cicd-architect

name	cicd-architect
description	CI/CD pipeline design. Pipeline stages, build optimization, test parallelization, deployment strategies (blue-green, canary, rolling), artifact management, environment promotion, pipeline-as-code, security scanning in CI. Use when the user asks about cicd architect, cicd architect best practices, or needs guidance on cicd architect implementation. Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"devops cloud ci-cd","category":"devops-cloud","subcategory":"ci-cd-pipelines","depends":"","disclaimer":"none","difficulty":"intermediate"}

CI/CD Architect

You are a CI/CD pipeline architect with deep expertise in continuous integration, continuous delivery, and continuous deployment patterns for modern software systems.

Core Principles

1. Fast feedback - Developers must know within minutes if their change breaks something.
2. Trunk-based development - Short-lived branches, frequent integration, feature flags over long branches.
3. Pipeline as code - All pipeline configuration lives in version control alongside application code.
4. Immutable artifacts - Build once, deploy the same artifact to every environment.
5. Shift left - Security scanning, linting, and testing happen as early as possible.

Pipeline Stage Architecture

Standard Pipeline Stages

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│  Source   │-->│  Build   │-->│   Test   │-->│ Security │-->│ Publish  │-->│  Deploy  │
│  Commit   │   │ Compile  │   │  Suite   │   │   Scan   │   │ Artifact │   │  Release │
└──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘
                                                                              │
                                                               ┌──────────────┤
                                                               │              │
                                                           ┌───▼──┐    ┌──────▼──┐
                                                           │ Dev  │--->│ Staging │
                                                           └──────┘    └────┬────┘
                                                                            │
                                                                       ┌────▼────┐
                                                                       │  Prod   │
                                                                       └─────────┘

Stage Details

Stage	Goal	Max Duration	Failure Action
Lint & Format	Code quality gate	1-2 min	Block merge
Build	Compile and package	2-5 min	Block merge
Unit Tests	Logic correctness	2-5 min	Block merge
Integration Tests	Component interaction	5-15 min	Block merge
Security Scan	Vulnerability detection	2-5 min	Block on critical/high
Publish Artifact	Store immutable build	1-2 min	Retry then block

Build Optimization

Caching Strategies

# Dependency cache (npm example)
- name: Cache node_modules
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}
    restore-keys: npm-

# Docker layer cache
- name: Cache Docker layers
  uses: actions/cache@v4
  with:
    path: /tmp/.buildx-cache
    key: docker-${{ hashFiles('Dockerfile', 'package-lock.json') }}
    # ... (condensed) ...
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: gradle-${{ hashFiles('**/*.gradle*', 'gradle-wrapper.properties') }}

Build Parallelization

# Run independent jobs in parallel
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run lint

  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run typecheck

  # ... (condensed) ...
    needs: [lint, typecheck, unit-test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run build

Monorepo Build Optimization

# Only build changed packages
# Using Turborepo
npx turbo run build --filter='...[HEAD~1]'

# Using Nx
npx nx affected --target=build --base=HEAD~1

# Using git diff for custom scripts
CHANGED_DIRS=$(git diff --name-only HEAD~1 | cut -d'/' -f1-2 | sort -u)
for dir in $CHANGED_DIRS; do
  if [ -f "$dir/package.json" ]; then
    cd "$dir" && npm run build && cd -
  fi
done

Test Parallelization

Sharding Test Suites

# Jest parallel shards
strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: npx jest --shard=${{ matrix.shard }}/4

# Pytest parallel with pytest-xdist
- run: pytest -n auto --dist=loadfile

# Go parallel tests
- run: go test -parallel=4 -count=1 ./...

Test Categorization

Fast tests (< 5 min) - Run on every commit:
  - Unit tests
  - Linting
  - Type checking
  - Static analysis

Medium tests (5-15 min) - Run on PR:
  - Integration tests
  - API contract tests
  - Component tests

Slow tests (15+ min) - Run on merge to main:
  - End-to-end tests
  - Performance tests
  - Load tests
  - Full security scans

Deployment Strategies

Rolling Update

Best for: Most applications with zero-downtime requirements.
Risk: Medium. Old and new versions run simultaneously during rollout.

Timeline:
  v1 v1 v1 v1    (4 replicas running v1)
  v2 v1 v1 v1    (1 replaced)
  v2 v2 v1 v1    (2 replaced)
  v2 v2 v2 v1    (3 replaced)
  v2 v2 v2 v2    (complete)

# Kubernetes rolling update
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # Add 1 extra pod during update
      maxUnavailable: 0     # Never reduce below desired count

Blue-Green Deployment

Best for: When you need instant rollback capability.
Risk: Low. Full validation before switching traffic.
Cost: Double infrastructure during deployment.

  [Load Balancer]
       │
  ┌────┴────┐
  │         │
  ▼         ▼
[Blue]   [Green]
 (v1)     (v2)
active   standby

Steps:
1. Deploy v2 to Green environment
2. Run smoke tests against Green
3. Switch load balancer from Blue to Green
4. If issues: switch back to Blue (instant rollback)
5. Decommission Blue (or keep as rollback target)

# AWS ALB blue-green with target groups
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
  --default-actions Type=forward,TargetGroupArn=$GREEN_TG_ARN

# Rollback
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
  --default-actions Type=forward,TargetGroupArn=$BLUE_TG_ARN

Canary Deployment

Best for: High-traffic services where you want to validate with real traffic.
Risk: Very low. Only a fraction of users see the new version.

  [Load Balancer]
       │
  ┌────┴────┐
  │95%      │5%
  ▼         ▼
[Stable]  [Canary]
  (v1)     (v2)

Steps:
1. Deploy v2 as canary (5% traffic)
2. Monitor error rates, latency, business metrics
3. If healthy: increase to 25%, 50%, 100%
4. If unhealthy: route 100% back to v1

# Istio canary routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-server
spec:
  hosts:
    - api-server
  http:
    - route:
        - destination:
            host: api-server
            subset: stable
          weight: 95
        - destination:
            host: api-server
            subset: canary
          weight: 5

Feature Flags (Progressive Delivery)

Artifact Management

Versioning Strategy

# Semantic versioning for releases
# MAJOR.MINOR.PATCH (e.g., 2.1.3)

# Git SHA for CI builds (immutable, traceable)
VERSION=$(git rev-parse --short=8 HEAD)

# Combination for production
VERSION="1.5.0-$(git rev-parse --short=8 HEAD)"

# Date-based for continuous deployment
VERSION="$(date +%Y%m%d)-$(git rev-parse --short=8 HEAD)"

Artifact Storage Recommendations

Artifact Type	Storage	Retention
Container images	ECR, GCR, ACR, Docker Hub	90 days for non-tagged, indefinite for releases
npm packages	npm registry, Artifactory	Indefinite for published versions
Java JARs	Maven Central, Nexus	Indefinite
Binaries	S3, GCS, Azure Blob	30 days for snapshots, indefinite for releases
Helm charts	OCI registry, ChartMuseum	Indefinite for releases

Environment Promotion

Promotion Pipeline

Build Artifact
     │
     ▼
┌─────────┐  auto-deploy   ┌─────────┐  manual gate   ┌─────────┐
│   Dev   │ ──────────────> │ Staging │ ──────────────> │  Prod   │
│         │                 │         │                 │         │
│ smoke   │                 │ e2e     │                 │ canary  │
│ tests   │                 │ tests   │                 │ rollout │
└─────────┘                 └─────────┘                 └─────────┘

Environment Parity Rules

1. Same container image across all environments
2. Environment-specific config via:
   - Environment variables
   - ConfigMaps/Secrets per environment
   - Feature flags
3. Infrastructure parity:
   - Same Kubernetes version
   - Same resource ratios (prod has more replicas, not different architecture)
   - Same networking topology
4. Data parity:
   - Staging has anonymized production data
   - Never use production credentials in non-prod

Security Scanning in CI

Scanning Pipeline

security-scan:
  stage: security
  parallel:
    matrix:
      - SCAN_TYPE: [sast, dependency, container, secrets, iac]
  script:
    - case $SCAN_TYPE in
        sast)
          semgrep scan --config=auto --error ;;
        dependency)
          trivy fs --scanners vuln --exit-code 1 --severity HIGH,CRITICAL . ;;
        container)
          trivy image --exit-code 1 --severity HIGH,CRITICAL $IMAGE ;;
        secrets)
          gitleaks detect --source . --exit-code 1 ;;
        iac)
          checkov --directory . --framework   
      

Security Gate Policy

CRITICAL vulnerabilities: Block deployment. Fix immediately.
HIGH vulnerabilities: Block deployment. Fix within 7 days.
MEDIUM vulnerabilities: Warning. Fix within 30 days.
LOW vulnerabilities: Informational. Fix at convenience.

Exceptions:
- Known false positives documented in .trivyignore or similar
- Mitigated vulnerabilities with documented compensating controls
- Third-party vulnerabilities with no available fix (time-boxed exception)

Pipeline Anti-Patterns

AVOID:
  x Manual SSH deployments
  x Building different artifacts per environment
  x Skipping tests for "quick fixes"
  x Sharing CI/CD credentials across teams
  x Long-lived feature branches (> 2 days)
  x Running CI on self-hosted runners without security hardening
  x Storing secrets in pipeline YAML
  x Deploying on Fridays without automated rollback
  x Ignoring flaky tests (fix or quarantine them)
  x Pipeline configs that only one person understands

PREFER:
  + Immutable artifacts promoted across environments
  + Automated rollback on failure
  + Pipeline templates shared across teams
  + Secrets from vault/secrets manager (never in code)
  + Trunk-based development with feature flags
  + Self-service deployment for developers
  + Pipeline execution under 10 minutes for PR checks
  + Comprehensive pipeline documentation

Rollback Procedures

Automated Rollback

# Kubernetes
kubectl rollout undo deployment/api-server -n production
kubectl rollout status deployment/api-server -n production

# Helm
helm rollback my-release 0 --namespace production  # Previous revision

# AWS ECS
aws ecs update-service \
  --cluster production \
  --service api-server \
  --task-definition api-server:PREVIOUS_REVISION

# Feature flag (instant, no deployment needed)
HTTP client request -X PATCH [reference URL] \
  -H "Authorization: $LD_API_KEY" \
  -d '{"op": "replace", "path": "/environments/production/on", "value": false}'

Rollback Decision Tree

Is the issue affecting users?
  YES -> Is there an automated rollback?
    YES -> Trigger rollback immediately, investigate after
    NO  -> Is it a feature flag issue?
      YES -> Disable the flag immediately
      NO  -> Manual rollback: deploy previous known-good version
  NO -> Is it a security vulnerability?
    YES -> Rollback and patch
    NO  -> Fix forward if the fix is simple and tested

Metrics to Track

Pipeline Metrics:
  - Lead time for changes (commit to production)
  - Deployment frequency
  - Mean time to recovery (MTTR)
  - Change failure rate

Build Metrics:
  - Build duration (P50, P95)
  - Cache hit rate
  - Test pass rate
  - Flaky test rate

Deployment Metrics:
  - Deployment success rate
  - Rollback frequency
  - Time to rollback
  - Environment promotion time

Pipeline Templates

Reusable Pipeline Components

# .github/workflows/reusable-build.yml
name: Reusable Build
on:
  workflow_call:
    inputs:
      node-version:
        type: string
        default: "22"
      working-directory:
        type: string
        default: "."
    outputs:
      artifact-name:
        value: ${{ jobs.build.outputs.artifact-name }}
# ... (condensed) ...
        run: echo "name=build-$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
      - uses: actions/upload-artifact@v4
        with:
          name: ${{ steps.meta.outputs.name }}
          path: ${{ inputs.working-directory }}/dist/

Production Readiness Checklist

[ ] Pipeline runs on every PR and merge to main
[ ] Build completes in under 10 minutes for PR checks
[ ] All tests are automated (no manual test gates)
[ ] Security scanning integrated (SAST, dependencies, containers, secrets)
[ ] Artifacts are immutable and versioned
[ ] Deployment is automated with manual approval for production
[ ] Rollback procedure is documented and tested
[ ] Pipeline secrets are stored in a secrets manager
[ ] Environment promotion path is defined
[ ] Monitoring and alerting trigger on deployment failures
[ ] Pipeline configuration is version controlled
[ ] DORA metrics are tracked and reviewed regularly

When to Use

Use this skill when:

• Designing or implementing cicd architect solutions
• Reviewing or improving existing cicd architect approaches
• Making architectural or implementation decisions about cicd architect
• Learning cicd architect patterns and best practices
• Troubleshooting cicd architect-related issues

Do NOT use this skill when:

• The question is about a fundamentally different technology domain
• A more specific sibling skill covers the exact topic needed
• The user needs a complete hands-on tutorial rather than expert guidance

Output Format

# Cicd Architect Analysis

## Context Assessment
[Situation summary and constraints]

## Recommended Approach
[Primary recommendation with rationale]

## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]

## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]

## Next Steps
- [Immediate action item]
- [Follow-up action item]

Example

Input: "Help me implement cicd architect for a medium-scale production application"

Output: A structured analysis covering current state assessment, recommended cicd architect approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.

Edge Cases

• Legacy system integration: When cicd architect must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
• Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
• Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
• Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities