بنقرة واحدة
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 |