[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70J101ZSZ7PBYFP7ZXTDFQY":3,"skill-same:01M70J101ZSZ7PBYFP7ZXTDFQY":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M70J101ZSZ7PBYFP7ZXTDFQY","deployment-pipeline-design",null,"Pipeline design, deployment strategies (blue-green, canary, rolling), and CI\u002FCD platform patterns. Use when designing pipelines, implementing deployments, configuring quality gates, or setting up automated release workflows. Covers GitHub Actions, GitLab CI, and platform-agnostic patterns.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Finfrastructure\u002Fdeployment-pipeline-design\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"design","deployment pipeline design","deployment","pipeline design","pipeline","patterns","CI\u002FCD","release","gitlab ci","gitlab","strategies","when","workflows","github actions","implementing","ci","up","actions","blue-green","green","2026-11-10 10:12:30",false,"---\nname: deployment-pipeline-design\ndescription: Pipeline design, deployment strategies (blue-green, canary, rolling), and CI\u002FCD platform patterns. Use when designing pipelines, implementing deployments, configuring quality gates, or setting up automated release workflows. Covers GitHub Actions, GitLab CI, and platform-agnostic patterns.\n---\n\n# CI\u002FCD Patterns\n\nA comprehensive skill for designing and implementing continuous integration and deployment pipelines. Covers pipeline architecture, deployment strategies, quality gates, and platform-specific patterns for GitHub Actions and GitLab CI.\n\n## When to Use\n\n- Designing new CI\u002FCD pipelines from scratch\n- Implementing deployment strategies (blue-green, canary, rolling)\n- Setting up quality gates and approval workflows\n- Configuring GitHub Actions or GitLab CI pipelines\n- Implementing automated rollback mechanisms\n- Creating multi-environment deployment workflows\n- Integrating security scanning into pipelines\n\n## Pipeline Architecture\n\n### Pipeline Stages\n\nA well-designed pipeline follows these stages in order:\n\n```\nBuild -> Test -> Analyze -> Package -> Deploy -> Verify\n```\n\n**Stage Breakdown:**\n\n| Stage | Purpose | Failure Action |\n|-------|---------|----------------|\n| Build | Compile code, resolve dependencies | Fail fast, notify developer |\n| Test | Unit tests, integration tests | Block deployment |\n| Analyze | SAST, linting, code coverage | Block or warn based on threshold |\n| Package | Create artifacts, container images | Fail fast |\n| Deploy | Push to environment | Rollback on failure |\n| Verify | Smoke tests, health checks | Trigger rollback |\n\n### Pipeline Design Principles\n\n1. **Fail Fast**: Run quick checks (lint, unit tests) before slow ones\n2. **Parallel Execution**: Run independent jobs concurrently\n3. **Artifact Caching**: Cache dependencies between runs\n4. **Immutable Artifacts**: Build once, deploy everywhere\n5. **Environment Parity**: Dev, staging, and prod should be identical\n\n## Deployment Strategies\n\n### Blue-Green Deployment\n\nTwo identical production environments where traffic switches instantly.\n\n```\n                    Load Balancer\n                         |\n            +------------+------------+\n            |                         |\n        [Blue v1.0]              [Green v1.1]\n         (active)                 (standby)\n```\n\n**When to Use:**\n- Zero-downtime requirements\n- Need instant rollback capability\n- Sufficient infrastructure budget for duplicate environments\n\n**Implementation Steps:**\n1. Deploy new version to inactive environment (Green)\n2. Run smoke tests against Green\n3. Switch load balancer to Green\n4. Monitor for issues\n5. Keep Blue running for quick rollback\n6. After confidence period, Blue becomes next deployment target\n\n**Rollback:** Switch load balancer back to Blue (seconds)\n\n### Canary Deployment\n\nGradually shift traffic from old version to new version.\n\n```\nTraffic Distribution Over Time:\n\nT0:  [====== v1.0 100% ======]\nT1:  [=== v1.0 95% ===][v1.1 5%]\nT2:  [== v1.0 75% ==][= v1.1 25% =]\nT3:  [= v1.0 50% =][== v1.1 50% ==]\nT4:  [====== v1.1 100% ======]\n```\n\n**When to Use:**\n- High-risk deployments\n- Need to validate with real traffic\n- Want gradual rollout with monitoring\n\n**Traffic Progression (Example):**\n1. 5% for 15 minutes - validate basic functionality\n2. 25% for 30 minutes - monitor error rates\n3. 50% for 1 hour - check performance metrics\n4. 100% - full rollout\n\n**Rollback Triggers:**\n- Error rate exceeds baseline + threshold\n- Latency exceeds acceptable limits\n- Health check failures\n\n### Rolling Deployment\n\nReplace instances incrementally, one batch at a time.\n\n```\nInstance Pool (5 instances):\n\nT0: [v1.0] [v1.0] [v1.0] [v1.0] [v1.0]\nT1: [v1.1] [v1.0] [v1.0] [v1.0] [v1.0]\nT2: [v1.1] [v1.1] [v1.0] [v1.0] [v1.0]\nT3: [v1.1] [v1.1] [v1.1] [v1.0] [v1.0]\nT4: [v1.1] [v1.1] [v1.1] [v1.1] [v1.0]\nT5: [v1.1] [v1.1] [v1.1] [v1.1] [v1.1]\n```\n\n**When to Use:**\n- Limited infrastructure resources\n- Can tolerate mixed versions during deployment\n- Stateless applications\n\n**Configuration Parameters:**\n- `maxUnavailable`: How many instances can be down simultaneously\n- `maxSurge`: How many extra instances during deployment\n- `minReadySeconds`: Wait time before considering instance healthy\n\n### Feature Flags\n\nDecouple deployment from release - deploy code without activating features.\n\n```\nCode deployed with feature flag:\n\nif (featureFlags.isEnabled('new-checkout', user)) {\n  return newCheckoutFlow(cart);\n} else {\n  return legacyCheckoutFlow(cart);\n}\n```\n\n**When to Use:**\n- Long-running feature development\n- A\u002FB testing requirements\n- Gradual feature rollouts\n- Kill switch for problematic features\n\n**Rollback:** Disable flag (no deployment required)\n\n## Quality Gates\n\n### Required Gates\n\nEvery pipeline should include these gates:\n\n| Gate | Threshold | Block Deploy? |\n|------|-----------|---------------|\n| Unit Tests | 100% pass | Yes |\n| Integration Tests | 100% pass | Yes |\n| Code Coverage | >= 80% | Yes |\n| Security Scan (Critical) | 0 findings | Yes |\n| Security Scan (High) | 0 new findings | Configurable |\n| Dependency Vulnerabilities | 0 critical | Yes |\n\n### Manual Approval Gates\n\nUse for production deployments:\n\n```yaml\n# Conceptual flow\nstages:\n  - test\n  - deploy-staging\n  - approval        # Manual gate\n  - deploy-prod\n  - verify\n```\n\n**Approval Requirements:**\n- At least 2 approvers for production\n- No self-approval allowed\n- Time-boxed approval windows\n- Audit trail of approvals\n\n## GitHub Actions Patterns\n\n### Basic Pipeline Structure\n\n```yaml\nname: CI\u002FCD Pipeline\n\non:\n  push:\n    branches: [main, develop]\n  pull_request:\n    branches: [main]\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n      - run: npm ci\n      - run: npm run build\n      - uses: actions\u002Fupload-artifact@v4\n        with:\n          name: build\n          path: dist\u002F\n\n  test:\n    needs: build\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fdownload-artifact@v4\n        with:\n          name: build\n          path: dist\u002F\n      - run: npm ci\n      - run: npm test\n\n  deploy-staging:\n    needs: test\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: staging\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with:\n          name: build\n      - run: .\u002Fdeploy.sh staging\n\n  deploy-prod:\n    needs: deploy-staging\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: production\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with:\n          name: build\n      - run: .\u002Fdeploy.sh production\n```\n\n### Matrix Builds\n\nRun tests across multiple configurations:\n\n```yaml\njobs:\n  test:\n    strategy:\n      fail-fast: false\n      matrix:\n        os: [ubuntu-latest, windows-latest, macos-latest]\n        node: [18, 20, 22]\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: ${{ matrix.node }}\n      - run: npm ci\n      - run: npm test\n```\n\n### Reusable Workflows\n\nCreate reusable workflow in `.github\u002Fworkflows\u002Fdeploy-reusable.yml`:\n\n```yaml\nname: Reusable Deploy\n\non:\n  workflow_call:\n    inputs:\n      environment:\n        required: true\n        type: string\n    secrets:\n      DEPLOY_KEY:\n        required: true\n\njobs:\n  deploy:\n    environment: ${{ inputs.environment }}\n    runs-on: ubuntu-latest\n    steps:\n      - run: .\u002Fdeploy.sh ${{ inputs.environment }}\n        env:\n          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}\n```\n\nCall from another workflow:\n\n```yaml\njobs:\n  deploy-staging:\n    uses: .\u002F.github\u002Fworkflows\u002Fdeploy-reusable.yml\n    with:\n      environment: staging\n    secrets:\n      DEPLOY_KEY: ${{ secrets.STAGING_DEPLOY_KEY }}\n```\n\n### Environment Protection Rules\n\nConfigure in repository settings:\n\n- Required reviewers for production\n- Wait timer (e.g., 15 minutes before prod deploy)\n- Restrict to specific branches\n- Required status checks\n\n## GitLab CI Patterns\n\n### Basic Pipeline Structure\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nvariables:\n  NODE_VERSION: \"20\"\n\ndefault:\n  image: node:${NODE_VERSION}\n  cache:\n    paths:\n      - node_modules\u002F\n\nbuild:\n  stage: build\n  script:\n    - npm ci\n    - npm run build\n  artifacts:\n    paths:\n      - dist\u002F\n    expire_in: 1 hour\n\ntest:unit:\n  stage: test\n  script:\n    - npm ci\n    - npm run test:unit\n  coverage: '\u002FCoverage: \\d+\\.\\d+%\u002F'\n\ntest:integration:\n  stage: test\n  services:\n    - postgres:15\n  variables:\n    POSTGRES_DB: test\n    POSTGRES_USER: test\n    POSTGRES_PASSWORD: test\n  script:\n    - npm ci\n    - npm run test:integration\n\ndeploy:staging:\n  stage: deploy\n  environment:\n    name: staging\n    url: https:\u002F\u002Fstaging.example.com\n  script:\n    - .\u002Fdeploy.sh staging\n  only:\n    - main\n\ndeploy:production:\n  stage: deploy\n  environment:\n    name: production\n    url: https:\u002F\u002Fexample.com\n  script:\n    - .\u002Fdeploy.sh production\n  when: manual\n  only:\n    - main\n```\n\n### Pipeline Rules\n\n```yaml\ndeploy:production:\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n    - if: $CI_COMMIT_TAG\n      when: on_success\n    - when: never\n```\n\n### Include Templates\n\n```yaml\ninclude:\n  - template: Security\u002FSAST.gitlab-ci.yml\n  - template: Security\u002FDependency-Scanning.gitlab-ci.yml\n  - local: .gitlab\u002Fci\u002Fdeploy.yml\n  - project: 'devops\u002Fci-templates'\n    ref: main\n    file: '\u002Ftemplates\u002Fdocker-build.yml'\n```\n\n### Dynamic Environments\n\n```yaml\ndeploy:review:\n  stage: deploy\n  environment:\n    name: review\u002F$CI_COMMIT_REF_SLUG\n    url: https:\u002F\u002F$CI_COMMIT_REF_SLUG.review.example.com\n    on_stop: stop:review\n  script:\n    - .\u002Fdeploy.sh review\n  only:\n    - merge_requests\n\nstop:review:\n  stage: deploy\n  environment:\n    name: review\u002F$CI_COMMIT_REF_SLUG\n    action: stop\n  script:\n    - .\u002Fteardown.sh review\n  when: manual\n  only:\n    - merge_requests\n```\n\n## Rollback Mechanisms\n\n### Automated Rollback Triggers\n\n```yaml\n# Conceptual rollback configuration\nrollback:\n  triggers:\n    - metric: error_rate\n      threshold: 5%\n      window: 5m\n    - metric: latency_p99\n      threshold: 2000ms\n      window: 5m\n    - metric: health_check_failures\n      threshold: 3\n      window: 1m\n  action:\n    type: previous_version\n    notify:\n      - slack: #deployments\n      - pagerduty: on-call\n```\n\n### Database Migration Rollback\n\n1. **Forward-only migrations** (preferred):\n   - Never use destructive operations (DROP, DELETE)\n   - Add new columns as nullable\n   - Use feature flags to switch behavior\n   - Clean up old columns in later release\n\n2. **Rollback migrations**:\n   - Every migration must have a corresponding rollback\n   - Test rollbacks in staging before production\n   - Keep rollback window defined (e.g., 24 hours)\n\n### Artifact-Based Rollback\n\n```yaml\nrollback:production:\n  stage: deploy\n  environment:\n    name: production\n  script:\n    - PREVIOUS_VERSION=$(get-previous-version.sh)\n    - .\u002Fdeploy.sh production $PREVIOUS_VERSION\n  when: manual\n  only:\n    - main\n```\n\n## Security Integration\n\n### SAST\u002FDAST Integration\n\n```yaml\nsecurity:sast:\n  stage: analyze\n  image: security-scanner:latest\n  script:\n    - sast-scan --format sarif --output sast-results.sarif\n  artifacts:\n    reports:\n      sast: sast-results.sarif\n\nsecurity:dependency:\n  stage: analyze\n  script:\n    - npm audit --audit-level=high\n    - trivy fs --security-checks vuln .\n```\n\n### Secret Scanning\n\n- Never commit secrets to repository\n- Use environment secrets or vault integration\n- Scan for exposed secrets in pre-commit hooks\n- Rotate secrets immediately if exposed\n\n## Best Practices\n\n### Pipeline Design\n\n- Keep pipelines under 15 minutes for main branch\n- Use caching aggressively for dependencies\n- Run expensive tests in parallel\n- Fail fast with quick checks first\n- Use artifacts to avoid rebuilding\n\n### Deployment Safety\n\n- Always have a rollback plan\n- Deploy to staging before production\n- Use feature flags for risky changes\n- Monitor deployments in real-time\n- Document deployment procedures\n\n### Quality Assurance\n\n- Enforce code coverage thresholds\n- Block deployments on security findings\n- Require peer approval for production\n- Maintain environment parity\n- Test rollback procedures regularly\n\n### Observability\n\n- Log all deployment events\n- Track deployment frequency and lead time\n- Monitor change failure rate\n- Measure mean time to recovery\n- Alert on deployment failures\n\n## References\n\n- `templates\u002Fpipeline-template.md` - Complete pipeline template with all stages\n","# CI\u002FCD Patterns\n\nA comprehensive skill for designing and implementing continuous integration and deployment pipelines. Covers pipeline architecture, deployment strategies, quality gates, and platform-specific patterns for GitHub Actions and GitLab CI.\n\n## When to Use\n\n- Designing new CI\u002FCD pipelines from scratch\n- Implementing deployment strategies (blue-green, canary, rolling)\n- Setting up quality gates and approval workflows\n- Configuring GitHub Actions or GitLab CI pipelines\n- Implementing automated rollback mechanisms\n- Creating multi-environment deployment workflows\n- Integrating security scanning into pipelines\n\n## Pipeline Architecture\n\n### Pipeline Stages\n\nA well-designed pipeline follows these stages in order:\n\n```\nBuild -> Test -> Analyze -> Package -> Deploy -> Verify\n```\n\n**Stage Breakdown:**\n\n| Stage | Purpose | Failure Action |\n|-------|---------|----------------|\n| Build | Compile code, resolve dependencies | Fail fast, notify developer |\n| Test | Unit tests, integration tests | Block deployment |\n| Analyze | SAST, linting, code coverage | Block or warn based on threshold |\n| Package | Create artifacts, container images | Fail fast |\n| Deploy | Push to environment | Rollback on failure |\n| Verify | Smoke tests, health checks | Trigger rollback |\n\n### Pipeline Design Principles\n\n1. **Fail Fast**: Run quick checks (lint, unit tests) before slow ones\n2. **Parallel Execution**: Run independent jobs concurrently\n3. **Artifact Caching**: Cache dependencies between runs\n4. **Immutable Artifacts**: Build once, deploy everywhere\n5. **Environment Parity**: Dev, staging, and prod should be identical\n\n## Deployment Strategies\n\n### Blue-Green Deployment\n\nTwo identical production environments where traffic switches instantly.\n\n```\n                    Load Balancer\n                         |\n            +------------+------------+\n            |                         |\n        [Blue v1.0]              [Green v1.1]\n         (active)                 (standby)\n```\n\n**When to Use:**\n- Zero-downtime requirements\n- Need instant rollback capability\n- Sufficient infrastructure budget for duplicate environments\n\n**Implementation Steps:**\n1. Deploy new version to inactive environment (Green)\n2. Run smoke tests against Green\n3. Switch load balancer to Green\n4. Monitor for issues\n5. Keep Blue running for quick rollback\n6. After confidence period, Blue becomes next deployment target\n\n**Rollback:** Switch load balancer back to Blue (seconds)\n\n### Canary Deployment\n\nGradually shift traffic from old version to new version.\n\n```\nTraffic Distribution Over Time:\n\nT0:  [====== v1.0 100% ======]\nT1:  [=== v1.0 95% ===][v1.1 5%]\nT2:  [== v1.0 75% ==][= v1.1 25% =]\nT3:  [= v1.0 50% =][== v1.1 50% ==]\nT4:  [====== v1.1 100% ======]\n```\n\n**When to Use:**\n- High-risk deployments\n- Need to validate with real traffic\n- Want gradual rollout with monitoring\n\n**Traffic Progression (Example):**\n1. 5% for 15 minutes - validate basic functionality\n2. 25% for 30 minutes - monitor error rates\n3. 50% for 1 hour - check performance metrics\n4. 100% - full rollout\n\n**Rollback Triggers:**\n- Error rate exceeds baseline + threshold\n- Latency exceeds acceptable limits\n- Health check failures\n\n### Rolling Deployment\n\nReplace instances incrementally, one batch at a time.\n\n```\nInstance Pool (5 instances):\n\nT0: [v1.0] [v1.0] [v1.0] [v1.0] [v1.0]\nT1: [v1.1] [v1.0] [v1.0] [v1.0] [v1.0]\nT2: [v1.1] [v1.1] [v1.0] [v1.0] [v1.0]\nT3: [v1.1] [v1.1] [v1.1] [v1.0] [v1.0]\nT4: [v1.1] [v1.1] [v1.1] [v1.1] [v1.0]\nT5: [v1.1] [v1.1] [v1.1] [v1.1] [v1.1]\n```\n\n**When to Use:**\n- Limited infrastructure resources\n- Can tolerate mixed versions during deployment\n- Stateless applications\n\n**Configuration Parameters:**\n- `maxUnavailable`: How many instances can be down simultaneously\n- `maxSurge`: How many extra instances during deployment\n- `minReadySeconds`: Wait time before considering instance healthy\n\n### Feature Flags\n\nDecouple deployment from release - deploy code without activating features.\n\n```\nCode deployed with feature flag:\n\nif (featureFlags.isEnabled('new-checkout', user)) {\n  return newCheckoutFlow(cart);\n} else {\n  return legacyCheckoutFlow(cart);\n}\n```\n\n**When to Use:**\n- Long-running feature development\n- A\u002FB testing requirements\n- Gradual feature rollouts\n- Kill switch for problematic features\n\n**Rollback:** Disable flag (no deployment required)\n\n## Quality Gates\n\n### Required Gates\n\nEvery pipeline should include these gates:\n\n| Gate | Threshold | Block Deploy? |\n|------|-----------|---------------|\n| Unit Tests | 100% pass | Yes |\n| Integration Tests | 100% pass | Yes |\n| Code Coverage | >= 80% | Yes |\n| Security Scan (Critical) | 0 findings | Yes |\n| Security Scan (High) | 0 new findings | Configurable |\n| Dependency Vulnerabilities | 0 critical | Yes |\n\n### Manual Approval Gates\n\nUse for production deployments:\n\n```yaml\n# Conceptual flow\nstages:\n  - test\n  - deploy-staging\n  - approval        # Manual gate\n  - deploy-prod\n  - verify\n```\n\n**Approval Requirements:**\n- At least 2 approvers for production\n- No self-approval allowed\n- Time-boxed approval windows\n- Audit trail of approvals\n\n## GitHub Actions Patterns\n\n### Basic Pipeline Structure\n\n```yaml\nname: CI\u002FCD Pipeline\n\non:\n  push:\n    branches: [main, develop]\n  pull_request:\n    branches: [main]\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n      - run: npm ci\n      - run: npm run build\n      - uses: actions\u002Fupload-artifact@v4\n        with:\n          name: build\n          path: dist\u002F\n\n  test:\n    needs: build\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fdownload-artifact@v4\n        with:\n          name: build\n          path: dist\u002F\n      - run: npm ci\n      - run: npm test\n\n  deploy-staging:\n    needs: test\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: staging\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with:\n          name: build\n      - run: .\u002Fdeploy.sh staging\n\n  deploy-prod:\n    needs: deploy-staging\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: production\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with:\n          name: build\n      - run: .\u002Fdeploy.sh production\n```\n\n### Matrix Builds\n\nRun tests across multiple configurations:\n\n```yaml\njobs:\n  test:\n    strategy:\n      fail-fast: false\n      matrix:\n        os: [ubuntu-latest, windows-latest, macos-latest]\n        node: [18, 20, 22]\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: ${{ matrix.node }}\n      - run: npm ci\n      - run: npm test\n```\n\n### Reusable Workflows\n\nCreate reusable workflow in `.github\u002Fworkflows\u002Fdeploy-reusable.yml`:\n\n```yaml\nname: Reusable Deploy\n\non:\n  workflow_call:\n    inputs:\n      environment:\n        required: true\n        type: string\n    secrets:\n      DEPLOY_KEY:\n        required: true\n\njobs:\n  deploy:\n    environment: ${{ inputs.environment }}\n    runs-on: ubuntu-latest\n    steps:\n      - run: .\u002Fdeploy.sh ${{ inputs.environment }}\n        env:\n          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}\n```\n\nCall from another workflow:\n\n```yaml\njobs:\n  deploy-staging:\n    uses: .\u002F.github\u002Fworkflows\u002Fdeploy-reusable.yml\n    with:\n      environment: staging\n    secrets:\n      DEPLOY_KEY: ${{ secrets.STAGING_DEPLOY_KEY }}\n```\n\n### Environment Protection Rules\n\nConfigure in repository settings:\n\n- Required reviewers for production\n- Wait timer (e.g., 15 minutes before prod deploy)\n- Restrict to specific branches\n- Required status checks\n\n## GitLab CI Patterns\n\n### Basic Pipeline Structure\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nvariables:\n  NODE_VERSION: \"20\"\n\ndefault:\n  image: node:${NODE_VERSION}\n  cache:\n    paths:\n      - node_modules\u002F\n\nbuild:\n  stage: build\n  script:\n    - npm ci\n    - npm run build\n  artifacts:\n    paths:\n      - dist\u002F\n    expire_in: 1 hour\n\ntest:unit:\n  stage: test\n  script:\n    - npm ci\n    - npm run test:unit\n  coverage: '\u002FCoverage: \\d+\\.\\d+%\u002F'\n\ntest:integration:\n  stage: test\n  services:\n    - postgres:15\n  variables:\n    POSTGRES_DB: test\n    POSTGRES_USER: test\n    POSTGRES_PASSWORD: test\n  script:\n    - npm ci\n    - npm run test:integration\n\ndeploy:staging:\n  stage: deploy\n  environment:\n    name: staging\n    url: https:\u002F\u002Fstaging.example.com\n  script:\n    - .\u002Fdeploy.sh staging\n  only:\n    - main\n\ndeploy:production:\n  stage: deploy\n  environment:\n    name: production\n    url: https:\u002F\u002Fexample.com\n  script:\n    - .\u002Fdeploy.sh production\n  when: manual\n  only:\n    - main\n```\n\n### Pipeline Rules\n\n```yaml\ndeploy:production:\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n    - if: $CI_COMMIT_TAG\n      when: on_success\n    - when: never\n```\n\n### Include Templates\n\n```yaml\ninclude:\n  - template: Security\u002FSAST.gitlab-ci.yml\n  - template: Security\u002FDependency-Scanning.gitlab-ci.yml\n  - local: .gitlab\u002Fci\u002Fdeploy.yml\n  - project: 'devops\u002Fci-templates'\n    ref: main\n    file: '\u002Ftemplates\u002Fdocker-build.yml'\n```\n\n### Dynamic Environments\n\n```yaml\ndeploy:review:\n  stage: deploy\n  environment:\n    name: review\u002F$CI_COMMIT_REF_SLUG\n    url: https:\u002F\u002F$CI_COMMIT_REF_SLUG.review.example.com\n    on_stop: stop:review\n  script:\n    - .\u002Fdeploy.sh review\n  only:\n    - merge_requests\n\nstop:review:\n  stage: deploy\n  environment:\n    name: review\u002F$CI_COMMIT_REF_SLUG\n    action: stop\n  script:\n    - .\u002Fteardown.sh review\n  when: manual\n  only:\n    - merge_requests\n```\n\n## Rollback Mechanisms\n\n### Automated Rollback Triggers\n\n```yaml\n# Conceptual rollback configuration\nrollback:\n  triggers:\n    - metric: error_rate\n      threshold: 5%\n      window: 5m\n    - metric: latency_p99\n      threshold: 2000ms\n      window: 5m\n    - metric: health_check_failures\n      threshold: 3\n      window: 1m\n  action:\n    type: previous_version\n    notify:\n      - slack: #deployments\n      - pagerduty: on-call\n```\n\n### Database Migration Rollback\n\n1. **Forward-only migrations** (preferred):\n   - Never use destructive operations (DROP, DELETE)\n   - Add new columns as nullable\n   - Use feature flags to switch behavior\n   - Clean up old columns in later release\n\n2. **Rollback migrations**:\n   - Every migration must have a corresponding rollback\n   - Test rollbacks in staging before production\n   - Keep rollback window defined (e.g., 24 hours)\n\n### Artifact-Based Rollback\n\n```yaml\nrollback:production:\n  stage: deploy\n  environment:\n    name: production\n  script:\n    - PREVIOUS_VERSION=$(get-previous-version.sh)\n    - .\u002Fdeploy.sh production $PREVIOUS_VERSION\n  when: manual\n  only:\n    - main\n```\n\n## Security Integration\n\n### SAST\u002FDAST Integration\n\n```yaml\nsecurity:sast:\n  stage: analyze\n  image: security-scanner:latest\n  script:\n    - sast-scan --format sarif --output sast-results.sarif\n  artifacts:\n    reports:\n      sast: sast-results.sarif\n\nsecurity:dependency:\n  stage: analyze\n  script:\n    - npm audit --audit-level=high\n    - trivy fs --security-checks vuln .\n```\n\n### Secret Scanning\n\n- Never commit secrets to repository\n- Use environment secrets or vault integration\n- Scan for exposed secrets in pre-commit hooks\n- Rotate secrets immediately if exposed\n\n## Best Practices\n\n### Pipeline Design\n\n- Keep pipelines under 15 minutes for main branch\n- Use caching aggressively for dependencies\n- Run expensive tests in parallel\n- Fail fast with quick checks first\n- Use artifacts to avoid rebuilding\n\n### Deployment Safety\n\n- Always have a rollback plan\n- Deploy to staging before production\n- Use feature flags for risky changes\n- Monitor deployments in real-time\n- Document deployment procedures\n\n### Quality Assurance\n\n- Enforce code coverage thresholds\n- Block deployments on security findings\n- Require peer approval for production\n- Maintain environment parity\n- Test rollback procedures regularly\n\n### Observability\n\n- Log all deployment events\n- Track deployment frequency and lead time\n- Monitor change failure rate\n- Measure mean time to recovery\n- Alert on deployment failures\n\n## References\n\n- `templates\u002Fpipeline-template.md` - Complete pipeline template with all stages\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Finfrastructure\u002Fdeployment-pipeline-design",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill deployment-pipeline-design",{"tool":73,"command":74},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill deployment-pipeline-design",{"tool":76,"command":77},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill deployment-pipeline-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Finfrastructure\u002Fdeployment-pipeline-design\u002FSKILL.md",true,[81],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"templates\u002Fpipeline-template.md","REFERENCE","参考文档",15715,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Finfrastructure\u002Fdeployment-pipeline-design\u002Ftemplates\u002Fpipeline-template.md",[88,105,137,163,185,205],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":97,"publishedAt":52},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[94],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[98,99,100,101,102,103,104],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":117,"publishedAt":52},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[111,114],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":115,"categoryName":116,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[107,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","architecture","code","unknown","generated",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":147,"publishedAt":52},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[143,144],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":145,"categoryName":146,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[139,148,149,150,151,152,153,154,126,155,156,157,43,158,159,160,161,162],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","use","auto","types","Video","创作",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"publishedAt":52},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[169],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[171,172,139,173,174,161,175,176,177,178,179,180,181,182,124,183,43,158,118,184],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":195,"publishedAt":52},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[191,192,193,194],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":115,"categoryName":116,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":145,"categoryName":146,"taxonomyType":29,"taxonomyTypeDesc":30},[196,103,197,198,199,200,134,43,158,201,202,203,204],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":213,"publishedAt":52},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[211,212],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":145,"categoryName":146,"taxonomyType":29,"taxonomyTypeDesc":30},[214,103,215,122,216,202,43,197,200,158,203],"Rules","writing rules","project rules"]