From nw
Outlines CI/CD pipelines with local quality gates, GitHub Actions patterns, branch strategies, and progressive deployments like canary/blue-green. For designing deployment workflows.
npx claudepluginhub nwave-ai/nwave --plugin nwThis skill uses the workspace's default tool permissions.
Catch issues at the developer's machine before they reach CI. Local gates mirror the remote commit stage for fast feedback (seconds vs minutes).
Designs multi-stage CI/CD pipelines with approval gates, security checks, and strategies like rolling, canary, blue-green for GitOps and continuous delivery.
Automates CI/CD pipeline setup with quality gates for linting, type checking, testing, building, security audits, and deployments using GitHub Actions. Use for new projects, modifying pipelines, or debugging failures.
Designs multi-stage CI/CD pipelines with source/build/test/staging/approval/production stages, manual/time-based/multi-approver gates, and strategies like rolling, canary, blue-green. Includes GitHub Actions, GitLab CI, Azure Pipelines examples.
Share bugs, ideas, or general feedback.
Catch issues at the developer's machine before they reach CI. Local gates mirror the remote commit stage for fast feedback (seconds vs minutes).
| Gate | Trigger | Checks | Tools |
|---|---|---|---|
| Pre-commit | git commit | Formatting, linting, unit tests, secrets scan | pre-commit, husky, lefthook |
| Pre-push | git push | Integration tests, acceptance tests, coverage threshold | pre-commit (push stage), git hooks |
| Local CI | Manual | Full pipeline locally | act (GitHub Actions), gitlab-runner exec |
--no-verify for emergencies but log skips. CI remains the authoritative gate.pre-commit (Python ecosystem) or lefthook (polyglot, fast parallel execution) over raw git hooks. Husky for JS/TS-heavy projects.pre-commit (< 30s): formatting | linting | unit tests (fast subset) | secrets scan
pre-push (< 5 min): full unit suite | integration tests | coverage check | type checking
Compile/build | Run unit tests (fast, isolated) | Static code analysis (linting, formatting) | Security scanning (SAST, secrets detection) | Generate build artifacts. Quality gates: build success | 100% unit test pass rate | coverage threshold (e.g., > 80%) | no critical vulnerabilities | no secrets in code.
Deploy to test environment | Run acceptance/integration/contract tests | Security scanning (DAST). Quality gates: 100% acceptance/integration pass rate | no high/critical security findings | API contracts validated.
Performance, load, and stress testing | Chaos engineering experiments. Quality gates: performance within SLO thresholds | load test pass (expected traffic + margin) | resilience under failure.
Progressive deployment (canary/blue-green) | Health checks and smoke tests | SLO monitoring during rollout | Automatic rollback on degradation. Quality gates: health checks pass | SLOs maintained | no error rate increase | latency within bounds.
Every quality gate has a category (where it runs), a type (what happens on failure), and a scope (what it protects).
| Category | Stage | Type | Examples |
|---|---|---|---|
| Local | Pre-commit, pre-push | Blocking (developer) | Format, lint, unit tests, secrets scan |
| PR | Pull request | Blocking (merge) | Status checks, review approvals, coverage diff |
| CI | Commit stage | Blocking (pipeline) | Build, unit tests, SAST, coverage threshold |
| CI | Acceptance stage | Blocking (pipeline) | Integration, acceptance, contract tests, DAST |
| Deploy | Environment promotion | Blocking (approval) | Manual approval, change advisory board |
| Deploy | Canary/progressive | Automatic (rollback) | Error rate, latency, SLO breach |
| Production | Post-deploy | Advisory (monitoring) | Smoke tests, SLO monitoring window, business metrics |
When designing quality gates for a pipeline, verify:
Triggers: push to main/develop | pull_request | release tags | manual workflow_dispatch.
Jobs flow: build -> security -> deploy_staging -> deploy_production. Each with appropriate needs dependencies and environment gates.
- name: Quality Gate
run: |
COVERAGE=$(jq '.totals.percent_covered' coverage.json)
if (( $(echo "$COVERAGE < 80" | bc -l) )); then
echo "Coverage $COVERAGE% is below 80% threshold"
exit 1
fi
- uses: actions/cache@v4
with:
path: ~/.cache/pip
key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-
strategy:
matrix:
python-version: ['3.10', '3.11', '3.12']
os: [ubuntu-latest, macos-latest]
Gradual replacement of instances. Kubernetes config: type: RollingUpdate, maxSurge: 25%, maxUnavailable: 0.
Two identical environments, instant switch: Blue (current) serves traffic -> Deploy new to Green -> Smoke tests on Green -> Switch load balancer -> Blue becomes standby/rollback.
Gradual traffic shift: 5% -> 25% -> 50% -> 100%, monitoring metrics at each step.
Argo Rollouts config:
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: {duration: 10m}
- setWeight: 25
- pause: {duration: 10m}
- setWeight: 50
- pause: {duration: 10m}
- setWeight: 100
analysis:
templates:
- templateName: success-rate
Feature flags + canary + automatic rollback. Components: feature flags for gradual rollout | canary analysis for automatic decisions | SLO monitoring for health validation. Tools: Argo Rollouts | Flagger | LaunchDarkly/Flagsmith.
Select branching strategy matching team maturity, release cadence, and risk profile. Shapes pipeline triggers, environment promotion, and release automation.
Single main branch, short-lived feature branches (< 1 day). Direct commits to main allowed with protection. Releases from main via tags.
push: [main], tags: ['v*']Feature branches from main, PRs with review, merge to main after approval. Releases from main.
pull_request: [main], push: [main]Structured branches: main (production) | develop (integration) | feature/* | release/* | hotfix/*.
push: [main, develop, 'release/**', 'hotfix/**'], pull_request: [develop]Long-lived release branches (e.g., release/1.x, release/2.x), cherry-pick fixes between branches.
push: [main, 'release/**']Require PR reviews (2+ approvers) | Require status checks to pass | Require signed commits | Require linear history | Restrict force pushes and deletions.
Semantic versioning (MAJOR.MINOR.PATCH): Create release branch -> Bump version -> Update CHANGELOG -> Run full test suite -> Create release tag -> Deploy to production -> Merge back to main.
Test execution architecture changes require simultaneous measurement strategy updates. Fundamental principle: treat test execution architecture and measurement strategy as tightly coupled concerns.
| Pitfall | Symptom | Prevention |
|---|---|---|
| False failure syndrome | Quality gates fail after CI/CD change without code changes | Validate measurement strategy in isolated environment first |
| Baseline drift | Increasing threshold adjustments without justification | Maintain versioned baseline documentation |
| Tool assumption violations | Inconsistent metrics across CI/CD runs | Review tool docs for architecture-specific behaviors |
Before: Analyze impact on test discovery | Identify affected measurement tools (coverage, mutation testing) | Document current baseline metrics. During: Adjust coverage thresholds for new execution model | Validate measurement strategy compatibility | Recalibrate quality gate thresholds. After: Establish new baseline metrics | Validate measurement accuracy against known scenarios | Update runbooks with measurement strategy changes.
Before proposing multi-service infrastructure (>3 components), document rejected simple alternatives:
Format:
## Rejected Simple Alternatives
### Alternative 1: {Simplest possible approach}
- **What**: {description}
- **Expected Impact**: {what % of requirements this meets}
- **Why Insufficient**: {specific, evidence-based reason}