| 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
- Fast feedback - Developers must know within minutes if their change breaks something.
- Trunk-based development - Short-lived branches, frequent integration, feature flags over long branches.
- Pipeline as code - All pipeline configuration lives in version control alongside application code.
- Immutable artifacts - Build once, deploy the same artifact to every environment.
- 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
- name: Cache node_modules
uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
restore-keys: npm-
- name: Cache Docker layers
uses: actions/cache@v4
with:
path: /tmp/.buildx-cache
key: docker-${{ hashFiles('Dockerfile', 'package-lock.json') }}
with:
path: |
~/.gradle/caches
~/.gradle/wrapper
key: gradle-${{ hashFiles('**/*.gradle*', 'gradle-wrapper.properties') }}
Build Parallelization
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
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
strategy:
matrix:
shard: [1, 2, 3, 4]
steps:
- run: npx jest --shard=${{ matrix.shard }}/4
- run: pytest -n auto --dist=loadfile
- 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)
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
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
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
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 }}
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
