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 Actionsbitbucket-pipelines.yml→ Bitbucket Pipelines.gitlab-ci.yml→ GitLab CIazure-pipelines.yml→ Azure PipelinesJenkinsfile→ Jenkins
Use 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 tsh-managing-secrets skill 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
- Discover context → Use
tsh-technical-context-discoveringto find existing CI patterns - Detect platform → Check for CI config files listed above
- Look up syntax → Use
context7for platform-specific YAML syntax - Choose deployment strategy → Use decision table above
- Configure credentials → Use
tsh-managing-secretsskill - 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
latesttags 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
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
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
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-approvewithout environment protection gates- Repeating
terraform initin every job without cache - Missing remote state backend configuration
- No plan artifact between plan and apply jobs
- Skipping security scanning (tfsec, checkov, trivy)
- Using
latestprovider 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 -
.terraformdirectory cached between runs
Related Skills
tsh-managing-secrets- For credential configurationtsh-technical-context-discovering- For finding existing patterns
Source: kkorus/cursor-collections — distributed by TomeVault.