# Cicd Architect > 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. - Skill: `ferroxlabs/cicd-architect` (Agent Skill) - Install (CLI): `npx skillmds@latest add ferroxlabs/cicd-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/ferroxlabs/cicd-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: Apache-2.0 - Author: FerroxLabs (https://skillmd.com/u/ferroxlabs) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ferroxlabs/cicd-architect --- # 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 ```yaml # 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 ```yaml # 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 ```shell # 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 ```yaml # 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) ``` ```yaml # 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) ``` ```shell # 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 ``` ```yaml # 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 ```shell # 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 ```yaml 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 terraform --soft-fail ;; esac ``` ### 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 ```shell # 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 ```yaml # .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 ```markdown # 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