cicd

Name: cicd
Author: krzysztofsurdy

36installs1forks

How to install cicd?

krzysztofsurdy/code-virtuoso/cicd

$npx -y skills add krzysztofsurdy/code-virtuoso --skill cicd

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# CI/CD Pipeline Patterns and Deployment Strategies
2
3	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.
4
5	## CI vs CD vs CD
6
7	\| Practice \| What It Automates \| Gate to Next Stage \|
8	\|---\|---\|---\|
9	\| Continuous Integration \| Merging, building, and testing code on every commit \| Automated tests must pass before merge \|
10	\| Continuous Delivery \| Packaging and promoting artifacts through environments \| Manual approval before production deployment \|
11	\| Continuous Deployment \| Full path from commit to production without manual steps \| Automated quality gates replace human approval \|
12
13	Continuous Integration is the foundation. Without reliable, fast integration, neither delivery nor deployment is sustainable. Start here and expand outward.
14
15	---
16
17	## Pipeline Design Principles
18
19	A well-designed pipeline gives developers fast, trustworthy feedback while preventing broken code from reaching users.
20
21	\| Principle \| Meaning \|
22	\|---\|---\|
23	\| Fast feedback \| Run the cheapest, fastest checks first - lint and unit tests before integration tests and builds \|
24	\| Fail early \| Stop the pipeline at the first failure - do not waste time on downstream stages when upstream checks fail \|
25	\| Reproducibility \| Every pipeline run with the same inputs must produce the same outputs - pin dependencies, use immutable base images \|
26	\| Idempotency \| Re-running a pipeline stage should be safe and produce the same result \|
27	\| Isolation \| Each pipeline run operates in a clean environment - no shared state between runs \|
28	\| Security by default \| Secrets are injected at runtime, never stored in source - scan for vulnerabilities early \|
29
30	---
31
32	## Deployment Strategies Overview
33
34	\| Strategy \| Downtime \| Rollback Speed \| Infrastructure Cost \| Complexity \| Best For \|
35	\|---\|---\|---\|---\|---\|---\|
36	\| Blue-Green \| Zero \| Instant (traffic switch) \| 2x production \| Low \| Major releases, risk-averse teams \|
37	\| Canary \| Zero \| Fast (route traffic back) \| 1x + small canary slice \| Medium \| Data-driven teams, high-traffic services \|
38	\| Rolling \| Zero (if surge configured) \| Slow (reverse rollout) \| 1x (reuses existing) \| Low \| Stateless services, frequent small changes \|
39	\| Recreate \| Yes (brief) \| Slow (full redeploy) \| 1x \| Minimal \| Dev/staging environments, stateful apps that cannot run two versions \|
40	\| Feature Flags \| Zero \| Instant (toggle off) \| 1x \| Medium \| Progressive rollout, A/B testing, trunk-based development \|
41
42	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.
43
44	---
45
46	## Environment Management Overview
47
48	A typical promotion path moves artifacts through increasingly production-like environments:
49
50	```
51	dev -> staging -> production
52	```
53
54	Key principles:
55	- Artifact immutability - Build once, deploy the same artifact everywhere. Never rebuild for each environment.
56	- Configuration separation - Environment-specific values (database URLs, API keys, feature toggles) live outside the artifact.
57	- Parity - Staging should mirror production as closely as possible in infrastructure, data shape, and scale.
58	- Ephemeral environments - Spin up isolated environments per pull request for testing and review, then tear them down automatically.
59
60	---
61
62	## Quick Reference: Pipeline Anti-Patterns
63
64	\| Anti-Pattern \| Problem \| Fix \|
65	\|---\|---\|---\|
66	\| Rebuilding artifacts per environment \| Different binary in staging vs production \| Build once, promote the same artifact \|
67	\| Long-running monolithic pipeline \| Slow feedback, developers context-switch \| Parallelize stages, split into focused pipelines \|
68	\| Secrets in source control \| Credential leaks, compliance violations \| Use a secrets manager, inject at runtime \|
69	\| Manual environment setup \| Configuration drift, "works on my machine" \| Infrastructure as code, containerized builds \|
70	\| No rollback plan \| Extended outages when deployments fail \| Automate rollback, test it regularly \|
71	\| Skipping staging \| Production-only bugs discovered too late \| Always promote through at least one pre-production environment \|
72
73	---
74
75	## Reference Files
76
77	\| Reference \| Contents \|
78	\|---\|---\|
79	\| [Pipeline Design](references/pipeline-design.md) \| Pipeline st

People who liked this also viewed

6 picks

Type

cicd

36installs1forks

View on GitHub

How to install cicd?

krzysztofsurdy/code-virtuoso/cicd

$npx -y skills add krzysztofsurdy/code-virtuoso --skill cicd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# CI/CD Pipeline Patterns and Deployment Strategies
2
3	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.
4
5	## CI vs CD vs CD
6
7	\| Practice \| What It Automates \| Gate to Next Stage \|
8	\|---\|---\|---\|
9	\| Continuous Integration \| Merging, building, and testing code on every commit \| Automated tests must pass before merge \|
10	\| Continuous Delivery \| Packaging and promoting artifacts through environments \| Manual approval before production deployment \|
11	\| Continuous Deployment \| Full path from commit to production without manual steps \| Automated quality gates replace human approval \|
12
13	Continuous Integration is the foundation. Without reliable, fast integration, neither delivery nor deployment is sustainable. Start here and expand outward.
14
15	---
16
17	## Pipeline Design Principles
18
19	A well-designed pipeline gives developers fast, trustworthy feedback while preventing broken code from reaching users.
20
21	\| Principle \| Meaning \|
22	\|---\|---\|
23	\| Fast feedback \| Run the cheapest, fastest checks first - lint and unit tests before integration tests and builds \|
24	\| Fail early \| Stop the pipeline at the first failure - do not waste time on downstream stages when upstream checks fail \|
25	\| Reproducibility \| Every pipeline run with the same inputs must produce the same outputs - pin dependencies, use immutable base images \|
26	\| Idempotency \| Re-running a pipeline stage should be safe and produce the same result \|
27	\| Isolation \| Each pipeline run operates in a clean environment - no shared state between runs \|
28	\| Security by default \| Secrets are injected at runtime, never stored in source - scan for vulnerabilities early \|
29
30	---
31
32	## Deployment Strategies Overview
33
34	\| Strategy \| Downtime \| Rollback Speed \| Infrastructure Cost \| Complexity \| Best For \|
35	\|---\|---\|---\|---\|---\|---\|
36	\| Blue-Green \| Zero \| Instant (traffic switch) \| 2x production \| Low \| Major releases, risk-averse teams \|
37	\| Canary \| Zero \| Fast (route traffic back) \| 1x + small canary slice \| Medium \| Data-driven teams, high-traffic services \|
38	\| Rolling \| Zero (if surge configured) \| Slow (reverse rollout) \| 1x (reuses existing) \| Low \| Stateless services, frequent small changes \|
39	\| Recreate \| Yes (brief) \| Slow (full redeploy) \| 1x \| Minimal \| Dev/staging environments, stateful apps that cannot run two versions \|
40	\| Feature Flags \| Zero \| Instant (toggle off) \| 1x \| Medium \| Progressive rollout, A/B testing, trunk-based development \|
41
42	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.
43
44	---
45
46	## Environment Management Overview
47
48	A typical promotion path moves artifacts through increasingly production-like environments:
49
50	```
51	dev -> staging -> production
52	```
53
54	Key principles:
55	- Artifact immutability - Build once, deploy the same artifact everywhere. Never rebuild for each environment.
56	- Configuration separation - Environment-specific values (database URLs, API keys, feature toggles) live outside the artifact.
57	- Parity - Staging should mirror production as closely as possible in infrastructure, data shape, and scale.
58	- Ephemeral environments - Spin up isolated environments per pull request for testing and review, then tear them down automatically.
59
60	---
61
62	## Quick Reference: Pipeline Anti-Patterns
63
64	\| Anti-Pattern \| Problem \| Fix \|
65	\|---\|---\|---\|
66	\| Rebuilding artifacts per environment \| Different binary in staging vs production \| Build once, promote the same artifact \|
67	\| Long-running monolithic pipeline \| Slow feedback, developers context-switch \| Parallelize stages, split into focused pipelines \|
68	\| Secrets in source control \| Credential leaks, compliance violations \| Use a secrets manager, inject at runtime \|
69	\| Manual environment setup \| Configuration drift, "works on my machine" \| Infrastructure as code, containerized builds \|
70	\| No rollback plan \| Extended outages when deployments fail \| Automate rollback, test it regularly \|
71	\| Skipping staging \| Production-only bugs discovered too late \| Always promote through at least one pre-production environment \|
72
73	---
74
75	## Reference Files
76
77	\| Reference \| Contents \|
78	\|---\|---\|
79	\| [Pipeline Design](references/pipeline-design.md) \| Pipeline st

People who liked this also viewed

6 picks

Type