ci-cd-and-automation

Name: ci-cd-and-automation
Author: addyosmani

byaddyosmani· 31 skills

Installs

15k

Stars

80k

Forks

8.7k

How to install ci-cd-and-automation?

addyosmani/agent-skills/ci-cd-and-automation

$npx -y skills add addyosmani/agent-skills --skill ci-cd-and-automation

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/ci-cd-and-automation"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# CI/CD and Automation
2
3	## Overview
4
5	Automate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.
6
7	Shift Left: Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.
8
9	Faster is Safer: Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.
10
11	## When to Use
12
13	- Setting up a new project's CI pipeline
14	- Adding or modifying automated checks
15	- Configuring deployment pipelines
16	- When a change should trigger automated verification
17	- Debugging CI failures
18
19	## The Quality Gate Pipeline
20
21	Every change goes through these gates before merge:
22
23	```
24	Pull Request Opened
25	│
26	▼
27	┌─────────────────┐
28	│ LINT CHECK │ eslint, prettier
29	│ ↓ pass │
30	│ TYPE CHECK │ tsc --noEmit
31	│ ↓ pass │
32	│ UNIT TESTS │ jest/vitest
33	│ ↓ pass │
34	│ BUILD │ npm run build
35	│ ↓ pass │
36	│ INTEGRATION │ API/DB tests
37	│ ↓ pass │
38	│ E2E (optional) │ Playwright/Cypress
39	│ ↓ pass │
40	│ SECURITY AUDIT │ npm audit
41	│ ↓ pass │
42	│ BUNDLE SIZE │ bundlesize check
43	└─────────────────┘
44	│
45	▼
46	Ready for review
47	```
48
49	No gate can be skipped. If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.
50
51	## GitHub Actions Configuration
52
53	### Basic CI Pipeline
54
55	```yaml
56	# .github/workflows/ci.yml
57	name: CI
58
59	on:
60	pull_request:
61	branches: [main]
62	push:
63	branches: [main]
64
65	jobs:
66	quality:
67	runs-on: ubuntu-latest
68	steps:
69	- uses: actions/checkout@v4
70
71	- uses: actions/setup-node@v4
72	with:
73	node-version: '22'
74	cache: 'npm'
75
76	- name: Install dependencies
77	run: npm ci
78
79	- name: Lint
80	run: npm run lint
81
82	- name: Type check
83	run: npx tsc --noEmit
84
85	- name: Test
86	run: npm test -- --coverage
87
88	- name: Build
89	run: npm run build
90
91	- name: Security audit
92	run: npm audit --audit-level=high
93	```
94
95	### With Database Integration Tests
96
97	```yaml
98	integration:
99	runs-on: ubuntu-latest
100	services:
101	postgres:
102	image: postgres:16
103	env:
104	POSTGRES_DB: testdb
105	POSTGRES_USER: ci_user
106	POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
107	ports:
108	- 5432:5432
109	options: >-
110	--health-cmd pg_isready
111	--health-interval 10s
112	--health-timeout 5s
113	--health-retries 5
114
115	steps:
116	- uses: actions/checkout@v4
117	- uses: actions/setup-node@v4
118	with:
119	node-version: '22'
120	cache: 'npm'
121	- run: npm ci
122	- name: Run migrations
123	run: npx prisma migrate deploy
124	env:
125	DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
126	- name: Integration tests
127	run: npm run test:integration
128	env:
129	DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
130	```
131
132	> Note: Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.
133
134	### E2E Tests
135
136	```yaml
137	e2e:
138	runs-on: ubuntu-latest
139	steps:
140	- uses: actions/checkout@v4
141	- uses: actions/setup-node@v4
142	with:
143	node-version: '22'
144	cache: 'npm'
145	- run: npm ci
146	- name: Install Playwright
147	run: npx playwright install --with-deps chromium
148	- name: Build
149	run: npm run build
150	- name: Run E2E tests
151	run: npx playwright test
152	- uses: actions/upload-artifact@v4
153	if: failure()
154	with:
155	name: playwright-report
156	path: playwright-report/
157	```
158
159	## Feeding CI Failures Back to Agents
160
161	The power of CI with AI agents is the feedback loop. When CI fails:
162
163	```
164	CI fails
165	│
166	▼
167	Copy the failure output
168	│
169	▼
170	Feed it to the agent:
171	"The CI pipeline failed with this error:
172	[paste specific error]
173	Fix the issue and verify locally before pushing again."
174	│
175	▼
176	Agent fixes → pushes → CI runs again
177	```
178
179	Key patterns:
180
181	```
182	Lint failure → Agent runs `npm run lint --fix` and commits
183	Type error → Agent reads the error location and fixes the type
184	Test failure → Agent follows debugging-and-error-recovery skill
185	Build error → Agent checks config and dependencies
186	```
187
188	## Deployment Strategies
189
190	### Preview Deployments
191
192	Every PR gets a preview deployment for manual testing:
193
194	```yaml
195	# Deploy preview on PR (Vercel/Netlify/etc.)
196	deploy-preview:
197	runs-on: ubuntu-latest
198	if: github.event_name == 'pull_request'
199	steps:
200	- uses: actions/checkout@v4
201	- name: Deploy preview
202	run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}
203	```
204
205	### Feature Flags
206
207	Feature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:
208
209	- Ship code without enabling it. Merge to main early, enable when ready.
210	- Roll back without redeploying. Disable the flag instead of reverting code.
211	- Canary new features. Enable for 1% of users, then 10%, then 100%.
212	- Run A/B tests. Compare behavior with and without the feature.
213
214	```typescript
215	// Simple feature flag pattern
216	if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
217	return renderNewCheckout();
218	}
219	return renderLegacyCheckout();
220	```
221
222	Flag lifecycle: Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.
223
224	### Staged Rollouts
225
226	```
227	PR merged to main
228	│
229	▼
230	Staging deployment (auto)
231	│ Manual verification
232	▼
233	Production deployment (manual trigger or auto after staging)
234	│
235	▼
236	Monitor for errors (15-minute window)
237	│
238	├── Errors detected → Rollback
239	└── Clean → Done
240	```
241
242	### Rollback Plan
243
244	Every deployment should be reversible:
245
246	```yaml
247	# Manual rollback workflow
248	name: Rollback
249	on:
250	workflow_dispatch:
251	inputs:
252	version:
253	description: 'Version to rollback to'
254	required: true
255
256	jobs:
257	rollback:
258	runs-on: ubuntu-latest
259	steps:
260	- name: Rollback deployment
261	run: \|
262	# Deploy the specified previous version
263	npx vercel rollback ${{ inputs.version }}
264	```
265
266	## Environment Management
267
268	```
269	.env.example → Committed (template for developers)
270	.env → NOT committed (local development)
271	.env.test → Committed (test environment, no real secrets)
272	CI secrets → Stored in GitHub Secrets / vault
273	Production secrets → Stored in deployment platform / vault
274	```
275
276	CI should never have production secrets. Use separate secrets for CI testing.
277
278	## Automation Beyond CI
279
280	### Dependabot / Renovate
281
282	```yaml
283	# .github/dependabot.yml
284	version: 2
285	updates:
286	- package-ecosystem: npm
287	directory: /
288	schedule:
289	interval: weekly
290	open-pull-requests-limit: 5
291	```
292
293	### Build Cop Role
294
295	Designate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.
296
297	### PR Checks
298
299	- Required reviews: At least 1 approval before merge
300	- Required status checks: CI must pass before merge
301	- Branch protection: No force-pushes to main
302	- Auto-merge: If all checks pass and approved, merge automatically
303
304	## CI Optimization
305
306	When the pipeline exceeds 10 minutes, apply these strategies in order of impact:
307
308	```
309	Slow CI pipeline?
310	├── Cache dependencies
311	│ └── Use actions/cache or setup-node cache option for node_modules
312	├── Run jobs in parallel
313	│ └── Split lint, typecheck, test, build into separate parallel jobs
314	├── Only run what changed
315	│ └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
316	├── Use matrix builds
317	│ └── Shard test suites across multiple runners
318	├── Optimize the test suite
319	│ └── Remove slow tests from the critical path, run them on a schedule instead
320	└── Use larger runners
321	└── GitHub-hosted larger runners or self-hosted for CPU-heavy builds
322	```
323
324	Example: caching and parallelism
325	```yaml
326	jobs:
327	lint:
328	runs-on: ubuntu-latest
329	steps:
330	- uses: actions/checkout@v4
331	- uses: actions/setup-node@v4
332	with: { node-version: '22', cache: 'npm' }
333	- run: npm ci
334	- run: npm run lint
335
336	typecheck:
337	runs-on: ubuntu-latest
338	steps:
339	- uses: actions/checkout@v4
340	- uses: actions/setup-node@v4
341	with: { node-version: '22', cache: 'npm' }
342	- run: npm ci
343	- run: npx tsc --noEmit
344
345	test:
346	runs-on: ubuntu-latest
347	steps:
348	- uses: actions/checkout@v4
349	- uses: actions/setup-node@v4
350	with: { node-version: '22', cache: 'npm' }
351	- run: npm ci
352	- run: npm test -- --coverage
353	```
354
355	## Common Rationalizations
356
357	\| Rationalization \| Reality \|
358	\|---\|---\|
359	\| "CI is too slow" \| Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline prevents hours of debugging. \|
360	\| "This change is trivial, skip CI" \| Trivial changes break builds. CI is fast for trivial changes anyway. \|
361	\| "The test is flaky, just re-run" \| Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. \|
362	\| "We'll add CI later" \| Projects without CI accumulate broken states. Set it up on day one. \|
363	\| "Manual testing is enough" \| Manual testing doesn't scale and isn't repeatable. Automate what you can. \|
364
365	## Red Flags
366
367	- No CI pipeline in the project
368	- CI failures ignored or silenced
369	- Tests disabled in CI to make the pipeline pass
370	- Production deploys without staging verification
371	- No rollback mechanism
372	- Secrets stored in code or CI config files (not secrets manager)
373	- Long CI times with no optimization effort
374
375	## Verification
376
377	After setting up or modifying CI:
378
379	- [ ] All quality gates are present (lint, types, tests, build, audit)
380	- [ ] Pipeline runs on every PR and push to main
381	- [ ] Failures block merge (branch protection configured)
382	- [ ] CI results feed back into the development loop
383	- [ ] Secrets are stored in the secrets manager, not in code
384	- [ ] Deployment has a rollback mechanism
385	- [ ] Pipeline runs in under 10 minutes for the test suite

6 picks

Type

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/ci-cd-and-automation"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

ci-cd-and-automation

How to install ci-cd-and-automation?

Related

ci-cd-and-automation

How to install ci-cd-and-automation?

Related