一键导入
ci-cd-patterns
CI/CD: Pipeline strategy, testing stages, deployment patterns, and release workflows.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
CI/CD: Pipeline strategy, testing stages, deployment patterns, and release workflows.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Bun runtime: HTTP server, file I/O, SQLite, test runner, package manager, bundler — all-in-one JS toolchain.
Clerk: Drop-in auth UI, Organizations, User management, JWT templates, webhooks, Next.js middleware integration.
Gelişmiş masaüstü, tarayıcı ve işletim sistemi kontrol yeteneği. Görsel (koordinat tabanlı) fare/klavye otomasyonu, DOM manipülasyonu, pencere yönetimi, gelişmiş dosya, ağ ve süreç yönetimini kapsar.
Drizzle ORM: Schema definition, type-safe queries, migrations, relations, Postgres/SQLite/MySQL support.
Expo Router v3: File-based navigation, layouts, tabs, modals, deep linking, API routes, typed routes.
Flutter ile oyun geliştirme (Flame Engine vb.) ve karmaşık, büyük ölçekli mimariler kurma rehberi.
| name | ci-cd-patterns |
| description | CI/CD: Pipeline strategy, testing stages, deployment patterns, and release workflows. |
| triggers | {"extensions":[".yml",".yaml"],"filenames":[".github/workflows",".gitlab-ci.yml","Jenkinsfile",".circleci"],"keywords":["pipeline","deploy","CI","CD","workflow","release"]} |
| auto_load_when | Editing CI/CD pipeline files |
| agent | devops-engineer |
| tools | ["Read","Write","Bash"] |
Focus: Build automation, testing strategy, deployment cadence
When to use what pipeline model:
├── Trunk-based (short-lived branches)
│ └── Use when: small teams, fast feedback needed
│ └── Avoid when: large teams, complex integration
│
├── GitFlow (long-lived branches)
│ └── Use when: scheduled releases, mature products
│ └── Avoid when: need rapid iteration
│
└── Release branches
└── Use when: multiple versions in production
└── Avoid when: single version, frequent releases
Test pyramid (bottom to top):
├── Unit tests (70%)
│ ├── Run: every commit
│ ├── Fast (< 1min total)
│ └── Coverage: core business logic
│
├── Integration tests (20%)
│ ├── Run: every PR
│ ├── Medium (1-10min)
│ └── Coverage: API contracts, DB interactions
│
├── E2E tests (10%)
│ ├── Run: before deploy
│ ├── Slow (10-30min)
│ └── Coverage: critical user journeys
│
└── Performance tests
├── Run: weekly or before major releases
└── Coverage: load handling, latency
When to use deployment strategy:
├── Blue-green
│ └── Use when: zero-downtime required
│ └── Swap: instant traffic switch
│ └── Rollback: instant revert
│
├── Canary
│ └── Use when: testing new version with real traffic
│ └── Approach: 1% → 10% → 100%
│ └── Rollback: redirect traffic back
│
├── Rolling
│ └── Use when: simple deployments, no downtime needed
│ └── Approach: replace instances one by one
│ └── Risk: partial deployment state
│
└── Feature flags
└── Use when: decoupling deploy from release
└── Approach: toggle features without redeploy
└── Benefit: gradual rollout, quick rollback
How to speed up CI:
├── Caching
│ ├── Dependencies: npm, pip, maven cache
│ ├── Build artifacts: compiled binaries, Docker layers
│ └── Test results: only rerun changed tests
│
├── Parallelization
│ ├── Split test suites by type
│ ├── Run independent jobs concurrently
│ └── Use matrix builds for multiple configs
│
└── Optimization
├── Skip builds for docs-only changes
├── Use shallow clones (git clone --depth 1)
└── Cache Docker layers between runs
Version strategy:
├── Semantic versioning (recommended)
│ ├── MAJOR: breaking changes
│ ├── MINOR: new features (backward compatible)
│ └── PATCH: bug fixes
│
├── Continuous deployment
│ └── Use when: high test confidence, fast feedback needed
│ └── Requirement: comprehensive test suite
│
└── Scheduled releases
└── Use when: business requires coordination
└── Requirement: release notes, changelog
❌ Deploying directly from developer laptops
✅ All deployments via CI/CD pipeline — never manual
❌ CI runs only on main branch
✅ Run CI on every PR — catch issues before merge
❌ No staging environment — dev → prod directly
✅ At minimum: dev → staging → prod with approval gates
❌ Secrets hardcoded in pipeline YAML
✅ Secrets from vault/secrets manager, injected as env vars
❌ Flaky tests causing random pipeline failures
✅ Quarantine flaky tests; fix or remove — never ignore
| Stage | What runs | Gate to next |
|---|---|---|
| Build | Compile, lint, typecheck | All pass |
| Test | Unit + integration tests | >80% coverage |
| Security | SAST, dependency audit | No criticals |
| Artifact | Docker build + push | Image tagged |
| Deploy staging | Helm/Terraform apply | Smoke tests pass |
| Deploy prod | Same image, prod values | Manual approval |