tsh-implementing-ci-cd

name	tsh-implementing-ci-cd
description	CI/CD pipeline design patterns and deployment strategies. Use when designing pipelines, implementing deployment strategies, or setting up automated delivery.
user-invocable	false

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 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

1. Discover context → Use tsh-technical-context-discovering to find existing CI patterns
2. Detect platform → Check for CI config files listed above
3. Look up syntax → Use context7 for platform-specific YAML syntax
4. Choose deployment strategy → Use decision table above
5. Configure credentials → Use tsh-managing-secrets skill
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

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-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

• tsh-managing-secrets - For credential configuration
• tsh-technical-context-discovering - For finding existing patterns