CI/CD Pipeline Patterns and Deployment Strategies
Continuous Integration, Continuous Delivery, and Continuous Deployment form a spectrum of automation practices. Each builds on the previous one, progressively reducing manual intervention between a code change and its availability to users.
CI vs CD vs CD
| Practice |
What It Automates |
Gate to Next Stage |
| Continuous Integration |
Merging, building, and testing code on every commit |
Automated tests must pass before merge |
| Continuous Delivery |
Packaging and promoting artifacts through environments |
Manual approval before production deployment |
| Continuous Deployment |
Full path from commit to production without manual steps |
Automated quality gates replace human approval |
Continuous Integration is the foundation. Without reliable, fast integration, neither delivery nor deployment is sustainable. Start here and expand outward.
Pipeline Design Principles
A well-designed pipeline gives developers fast, trustworthy feedback while preventing broken code from reaching users.
| Principle |
Meaning |
| Fast feedback |
Run the cheapest, fastest checks first - lint and unit tests before integration tests and builds |
| Fail early |
Stop the pipeline at the first failure - do not waste time on downstream stages when upstream checks fail |
| Reproducibility |
Every pipeline run with the same inputs must produce the same outputs - pin dependencies, use immutable base images |
| Idempotency |
Re-running a pipeline stage should be safe and produce the same result |
| Isolation |
Each pipeline run operates in a clean environment - no shared state between runs |
| Security by default |
Secrets are injected at runtime, never stored in source - scan for vulnerabilities early |
Deployment Strategies Overview
| Strategy |
Downtime |
Rollback Speed |
Infrastructure Cost |
Complexity |
Best For |
| Blue-Green |
Zero |
Instant (traffic switch) |
2x production |
Low |
Major releases, risk-averse teams |
| Canary |
Zero |
Fast (route traffic back) |
1x + small canary slice |
Medium |
Data-driven teams, high-traffic services |
| Rolling |
Zero (if surge configured) |
Slow (reverse rollout) |
1x (reuses existing) |
Low |
Stateless services, frequent small changes |
| Recreate |
Yes (brief) |
Slow (full redeploy) |
1x |
Minimal |
Dev/staging environments, stateful apps that cannot run two versions |
| Feature Flags |
Zero |
Instant (toggle off) |
1x |
Medium |
Progressive rollout, A/B testing, trunk-based development |
No single strategy fits every situation. Many teams combine approaches - for example, canary releases with feature flags for granular control over who sees new functionality.
Environment Management Overview
A typical promotion path moves artifacts through increasingly production-like environments:
dev -> staging -> production
Key principles:
- Artifact immutability - Build once, deploy the same artifact everywhere. Never rebuild for each environment.
- Configuration separation - Environment-specific values (database URLs, API keys, feature toggles) live outside the artifact.
- Parity - Staging should mirror production as closely as possible in infrastructure, data shape, and scale.
- Ephemeral environments - Spin up isolated environments per pull request for testing and review, then tear them down automatically.
Quick Reference: Pipeline Anti-Patterns
| Anti-Pattern |
Problem |
Fix |
| Rebuilding artifacts per environment |
Different binary in staging vs production |
Build once, promote the same artifact |
| Long-running monolithic pipeline |
Slow feedback, developers context-switch |
Parallelize stages, split into focused pipelines |
| Secrets in source control |
Credential leaks, compliance violations |
Use a secrets manager, inject at runtime |
| Manual environment setup |
Configuration drift, "works on my machine" |
Infrastructure as code, containerized builds |
| No rollback plan |
Extended outages when deployments fail |
Automate rollback, test it regularly |
| Skipping staging |
Production-only bugs discovered too late |
Always promote through at least one pre-production environment |
Reference Files
| Reference |
Contents |
| Pipeline Design |
Pipeline stages, parallelization, caching, monorepo patterns, secrets management with multi-format examples |
| Deployment Strategies |
Blue-green, canary, rolling deployments, feature flags, zero-downtime migrations, rollback strategies |
| Environment Management |
Environment promotion, infrastructure as code, ephemeral environments, artifact versioning, health checks |
Integration with Other Skills
| Situation |
Recommended Skill |
| Monitoring and observability for deployments |
Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for microservices patterns (circuit breakers, health checks) |
| Security scanning in pipelines |
Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for security practices (OWASP, secure coding) |
| Testing strategy for CI pipelines |
Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for testing pyramid and test design |
| API versioning during deployments |
Install knowledge-virtuoso from krzysztofsurdy/code-virtuoso for API design and evolution strategies |
1---2name: cicd3description: CI/CD pipeline patterns and deployment strategies for automated, reliable software delivery. Use when the user asks to design a build pipeline, choose a deployment model (blue-green, canary, rolling), configure environment promotion, manage build artifacts, implement zero-downtime deployments, set up quality gates, or improve delivery workflow speed and reliability. Covers pipeline stage ordering, test parallelization, caching, secrets in CI, and rollback strategies.4---56# CI/CD Pipeline Patterns and Deployment Strategies78Continuous Integration, Continuous Delivery, and Continuous Deployment form a spectrum of automation practices. Each builds on the previous one, progressively reducing manual intervention between a code change and its availability to users.910## CI vs CD vs CD1112| Practice | What It Automates | Gate to Next Stage |13|---|---|---|14| **Continuous Integration** | Merging, building, and testing code on every commit | Automated tests must pass before merge |15| **Continuous Delivery** | Packaging and promoting artifacts through environments | Manual approval before production deployment |16| **Continuous Deployment** | Full path from commit to production without manual steps | Automated quality gates replace human approval |1718Continuous Integration is the foundation. Without reliable, fast integration, neither delivery nor deployment is sustainable. Start here and expand outward.1920---2122## Pipeline Design Principles2324A well-designed pipeline gives developers fast, trustworthy feedback while preventing broken code from reaching users.2526| Principle | Meaning |27|---|---|28| **Fast feedback** | Run the cheapest, fastest checks first - lint and unit tests before integration tests and builds |29| **Fail early** | Stop the pipeline at the first failure - do not waste time on downstream stages when upstream checks fail |30| **Reproducibility** | Every pipeline run with the same inputs must produce the same outputs - pin dependencies, use immutable base images |31| **Idempotency** | Re-running a pipeline stage should be safe and produce the same result |32| **Isolation** | Each pipeline run operates in a clean environment - no shared state between runs |33| **Security by default** | Secrets are injected at runtime, never stored in source - scan for vulnerabilities early |3435---3637## Deployment Strategies Overview3839| Strategy | Downtime | Rollback Speed | Infrastructure Cost | Complexity | Best For |40|---|---|---|---|---|---|41| **Blue-Green** | Zero | Instant (traffic switch) | 2x production | Low | Major releases, risk-averse teams |42| **Canary** | Zero | Fast (route traffic back) | 1x + small canary slice | Medium | Data-driven teams, high-traffic services |43| **Rolling** | Zero (if surge configured) | Slow (reverse rollout) | 1x (reuses existing) | Low | Stateless services, frequent small changes |44| **Recreate** | Yes (brief) | Slow (full redeploy) | 1x | Minimal | Dev/staging environments, stateful apps that cannot run two versions |45| **Feature Flags** | Zero | Instant (toggle off) | 1x | Medium | Progressive rollout, A/B testing, trunk-based development |4647No single strategy fits every situation. Many teams combine approaches - for example, canary releases with feature flags for granular control over who sees new functionality.4849---5051## Environment Management Overview5253A typical promotion path moves artifacts through increasingly production-like environments:5455```56dev -> staging -> production57```5859Key principles:60- **Artifact immutability** - Build once, deploy the same artifact everywhere. Never rebuild for each environment.61- **Configuration separation** - Environment-specific values (database URLs, API keys, feature toggles) live outside the artifact.62- **Parity** - Staging should mirror production as closely as possible in infrastructure, data shape, and scale.63- **Ephemeral environments** - Spin up isolated environments per pull request for testing and review, then tear them down automatically.6465---6667## Quick Reference: Pipeline Anti-Patterns6869| Anti-Pattern | Problem | Fix |70|---|---|---|71| Rebuilding artifacts per environment | Different binary in staging vs production | Build once, promote the same artifact |72| Long-running monolithic pipeline | Slow feedback, developers context-switch | Parallelize stages, split into focused pipelines |73| Secrets in source control | Credential leaks, compliance violations | Use a secrets manager, inject at runtime |74| Manual environment setup | Configuration drift, "works on my machine" | Infrastructure as code, containerized builds |75| No rollback plan | Extended outages when deployments fail | Automate rollback, test it regularly |76| Skipping staging | Production-only bugs discovered too late | Always promote through at least one pre-production environment |7778---7980## Reference Files8182| Reference | Contents |83|---|---|84| [Pipeline Design](references/pipeline-design.md) | Pipeline stages, parallelization, caching, monorepo patterns, secrets management with multi-format examples |85| [Deployment Strategies](references/deployment-strategies.md) | Blue-green, canary, rolling deployments, feature flags, zero-downtime migrations, rollback strategies |86| [Environment Management](references/environment-management.md) | Environment promotion, infrastructure as code, ephemeral environments, artifact versioning, health checks |8788---8990## Integration with Other Skills9192| Situation | Recommended Skill |93|---|---|94| Monitoring and observability for deployments | Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for microservices patterns (circuit breakers, health checks) |95| Security scanning in pipelines | Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for security practices (OWASP, secure coding) |96| Testing strategy for CI pipelines | Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for testing pyramid and test design |97| API versioning during deployments | Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for API design and evolution strategies |
krzysztofsurdy