Cicd
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.From its SKILL.md
npx -y skills add krzysztofsurdy/code-virtuoso --skill cicdAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.0 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
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 |
What ships with it: 3 files
15.6 KB alongside SKILL.md
references/
- deployment-strategies.md5.3 KB
- environment-management.md5.7 KB
- pipeline-design.md4.7 KB
Gives 0 of the 12 instructions most ci cd skills give in ~1.2k tokens
Counted across 343 of the 355 authors here whose files we hold, read 2026-09-06
- Pin third-party actions to full commit SHAin 34 of 343, across 29 files
- Set timeout-minutes on every jobin 23 of 343, across 17 files
- Deploy to staging before productionin 18 of 343
- Use OIDC instead of stored cloud credentialsin 18 of 343, across 12 files
- Pin action versionsin 14 of 343, across 13 files
- Cache dependencies keyed on the lockfile hashin 14 of 343, across 13 files
- Declare least-privilege permissions at workflow and job levelin 13 of 343, across 7 files
- Pass untrusted values through env variablesin 13 of 343, across 9 files
- Create efficient GitHub Actions workflowsin 11 of 343, across 5 files
- Cache dependencies via setup actions or actions/cachein 11 of 343, across 5 files
- Cache dependencies to speed up buildsin 11 of 343
- Store secrets in secret managersin 11 of 343, across 10 files
Said here and by no other author read
- Pin dependencies and use immutable base images
- Make pipeline stages safe to rerun
- Run each pipeline in a clean environment
- Inject secrets at runtime
- Keep environment configuration outside the artifact
- Make staging mirror production closely
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.