CI/CD pipeline design patterns and deployment strategies. Use when designing pipelines, implementing deployment strategies, or setting up automated delivery.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add aiFabricoCom/fabrico-collections --skill fabrico-implementing-ci-cd --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Fabrico Implementing Ci Cd?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/aifabricocom-fabrico-implementing-ci-cd)More formats (shields.io, HTML) on the badges page.
---
name: fabrico-implementing-ci-cd
description: 'CI/CD pipeline design patterns and deployment strategies. Use when designing pipelines, implementing deployment strategies, or setting up automated delivery.'
---
# CI/CD Pipeline Patterns
## When to Use
- Designing new CI/CD pipelines
- Implementing deployment strategies (rolling, blue-green, canary)
- Setting up GitOps workflows
- Configuring secure CI/CD credentials
## Platform Detection
Check which CI/CD platform the project uses:
- `.github/workflows/*.yml` → GitHub Actions
- `bitbucket-pipelines.yml` → Bitbucket Pipelines
- `.gitlab-ci.yml` → GitLab CI
- `azure-pipelines.yml` → Azure Pipelines
- `Jenkinsfile` → Jenkins
Use the **context7** MCP server (tools `mcp__context7__*`) to look up platform-specific syntax for the detected platform.
## Pipeline Structure
```
Lint → Test → Build → Deploy (staging) → Deploy (production)
↓
Artifacts & Caching
```
**Rule:** Each stage should be independent and cacheable.
## Deployment Strategy Decision
| Strategy | Use When | Rollback | Risk |
|----------|----------|----------|------|
| **Rolling** | Stateless apps, can tolerate mixed versions | Slow | Low |
| **Blue-Green** | Need instant rollback, DB migrations | Instant | Low |
| **Canary** | High traffic, want gradual validation | Instant | Very Low |
| **Recreate** | Dev/test, breaking changes only | Slow | High |
## Credentials Strategy Decision
| Scenario | Approach |
|----------|----------|
| AWS from GitHub/GitLab | OIDC federation (no long-lived keys) |
| AWS from Bitbucket | Repository variables + IAM role |
| Multi-cloud | HashiCorp Vault with CI/CD auth |
| Simple/small team | Platform native secrets |
**Rule:** Prefer OIDC federation over long-lived access keys. Use the `fabrico-managing-secrets` skill (`.claude/skills/fabrico-managing-secrets/SKILL.md`) for implementation details.
## Monorepo Strategy
| Tool | Detection | Approach |
|------|-----------|----------|
| Nx | `nx.json` | `nx affected --target=build` |
| Turborepo | `turbo.json` | `turbo run build --filter=...[origin/main]` |
| None | - | Path filtering in CI config |
## Process
1. **Discover context** → Use the `fabrico-technical-context-discovering` skill (`.claude/skills/fabrico-technical-context-discovering/SKILL.md`) to find existing CI patterns
2. **Detect platform** → Check for CI config files listed above
3. **Look up syntax** → Use the **context7** MCP server (tools `mcp__context7__*`) for platform-specific YAML syntax
4. **Choose deployment strategy** → Use decision table above
5. **Configure credentials** → Use the `fabrico-managing-secrets` skill (`.claude/skills/fabrico-managing-secrets/SKILL.md`)
6. **Validate** → Run pipeline in dry-run/plan mode first
## Checklist
- [ ] Secrets stored in platform secret manager (not in code)
- [ ] Caching configured for dependencies
- [ ] Branch protection enabled on main/master
- [ ] Environment approvals required for production
- [ ] Rollback procedure documented
- [ ] Pipeline uses pinned versions (not `@latest`)
## Anti-Patterns
- Storing secrets in code or logs
- Skipping tests for "quick fixes"
- Using `latest` tags in production images
- Deploying without artifact verification
- Direct pushes to main/master
---
## Infrastructure as Code Pipelines
### Terraform/Terragrunt Pipeline Structure
```
Lint (fmt) → Validate → Security Scan → Plan → [Manual Approval] → Apply
↓
Save Plan Artifact
↓
PR Comment with Diff
```
**Rule:** Never use local state in CI/CD. Always configure remote backend before pipeline runs.
### Required Elements
| Element | Implementation | Why |
|---------|---------------|-----|
| AWS Credentials | `aws-actions/configure-aws-credentials@v4` with OIDC | No long-lived secrets |
| State Backend | S3 + DynamoDB locking | Persistent state, concurrent access protection |
| Plan Artifact | `terraform plan -out=tfplan` + upload artifact | Ensure apply matches reviewed plan |
| PR Comment | `actions/github-script` or `terraform-pr-commenter` | Reviewers see changes before merge |
| Security Scan | `aquasecurity/tfsec-action` or `bridgecrewio/checkov-action` | Catch misconfigurations early |
| Production Guard | `environment: production` with required reviewers | Human approval before infra changes |
| Cache | `actions/cache` for `.terraform` directory | Faster init, reduced API calls |
### GitHub Actions OIDC for AWS
```yaml
permissions:
id-token: write
contents: read
steps:
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-arn: ${{ secrets.AWS_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION }}
```
**Rule:** Always use OIDC federation. Never store AWS access keys as secrets.
### Environment Protection
```yaml
apply:
runs-on: ubuntu-latest
needs: plan
environment: production # Requires manual approval
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
```
Configure in GitHub: Settings → Environments → production → Required reviewers.
### Plan Artifact Pattern
```yaml
plan:
steps:
- run: terraform plan -out=tfplan
- uses: actions/upload-artifact@v4
with:
name: tfplan
path: tfplan
apply:
steps:
- uses: actions/download-artifact@v4
with:
name: tfplan
- run: terraform apply tfplan
```
**Rule:** Apply must use the exact plan that was reviewed, not regenerate it.
### IaC Anti-Patterns
- `apply -auto-approve` without environment protection gates
- Repeating `terraform init` in every job without cache
- Missing remote state backend configuration
- No plan artifact between plan and apply jobs
- Skipping security scanning (tfsec, checkov, trivy)
- Using `latest` provider versions instead of pinned versions
- Not posting plan output to PR for review
### IaC Checklist
- [ ] Remote state backend configured (S3/GCS/Azure Blob)
- [ ] State locking enabled (DynamoDB/native)
- [ ] OIDC federation for cloud credentials
- [ ] Security scanning in pipeline (tfsec/checkov)
- [ ] Plan artifact saved and reused in apply
- [ ] Plan diff posted as PR comment
- [ ] Environment protection on production
- [ ] Provider versions pinned in `versions.tf`
- [ ] `.terraform` directory cached between runs
---
## Related Skills
- `fabrico-managing-secrets` - For credential configuration
- `fabrico-technical-context-discovering` - For finding existing patterns
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!