jpskill.com
🛠️ 開発・MCP コミュニティ

cicd-pipeline

GitLab CIやCircleCIの継続的インテグレーション/継続的デリバリー(CI/CD)パイプラインを生成・最適化し、テスト自動化の追加やデプロイ自動化などを実現することで、開発プロセスを効率化するSkill。

📜 元の英語説明(参考)

Generate and optimize CI/CD pipelines for GitLab CI and CircleCI. Use when a user asks to set up GitLab CI, create a CircleCI pipeline, build a CI pipeline for GitLab, automate deployments with CircleCI, add test automation to GitLab, or configure continuous integration on non-GitHub platforms. For GitHub Actions pipelines, use the github-actions skill instead.

🇯🇵 日本人クリエイター向け解説

一言でいうと

GitLab CIやCircleCIの継続的インテグレーション/継続的デリバリー(CI/CD)パイプラインを生成・最適化し、テスト自動化の追加やデプロイ自動化などを実現することで、開発プロセスを効率化するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o cicd-pipeline.zip https://jpskill.com/download/14742.zip && unzip -o cicd-pipeline.zip && rm cicd-pipeline.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/14742.zip -OutFile "$d\cicd-pipeline.zip"; Expand-Archive "$d\cicd-pipeline.zip" -DestinationPath $d -Force; ri "$d\cicd-pipeline.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して cicd-pipeline.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → cicd-pipeline フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

CI/CD パイプライン (GitLab CI & CircleCI)

概要

自動テスト、ビルド、および GitLab CI と CircleCI 上でのアプリケーションのデプロイのために、本番環境に対応した CI/CD パイプライン構成を生成します。この skill は、適切なキャッシュ、マトリクステスト、環境分離、およびデプロイ戦略を備えた、構造化されたワークフローを作成します。GitHub Actions パイプラインについては、github-actions skill を使用してください。

手順

ユーザーが CI/CD パイプラインの作成または改善を依頼してきた場合は、以下の手順に従ってください。

ステップ 1: プロジェクトの分析

プロジェクトの種類と要件を検出します。

# 言語とフレームワークを特定
ls package.json pyproject.toml Gemfile go.mod Cargo.toml pom.xml build.gradle 2>/dev/null

# 既存の CI 構成を確認
ls .gitlab-ci.yml .circleci/config.yml 2>/dev/null

# テストコマンドを検出
cat package.json | grep -A5 '"scripts"' 2>/dev/null
cat Makefile 2>/dev/null | grep -E "^test|^lint|^build"

以下を特定します。

  • 言語/ランタイム: Node.js, Python, Go, Rust, Java
  • パッケージマネージャー: npm, pnpm, yarn, pip, poetry
  • テストフレームワーク: Jest, Pytest, Go test, etc.
  • ビルド出力: Docker image, static site, binary, package
  • デプロイ先: AWS, Docker registry, npm registry, SSH server

ステップ 2: CI/CD プラットフォームの選択

リポジトリが GitLab 上にある場合は、GitLab CI をデフォルトとします。指定された場合、またはプロジェクトにすでに .circleci/ ディレクトリがある場合は、CircleCI を使用します。

ステップ 3: パイプライン構成の生成

GitLab CI — Node.js の例:

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"

.node-cache:
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

lint:
  stage: lint
  extends: .node-cache
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  extends: .node-cache
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm test -- --coverage
  coverage: '/All files.*\|.*\s+([\d\.]+)/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

build:
  stage: build
  extends: .node-cache
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
  only:
    - main

GitLab CI — Docker ビルドとデプロイ:

build-image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - main

deploy:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
  script:
    - ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$DEPLOY_HOST "docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA && docker-compose up -d"
  when: manual
  only:
    - main

CircleCI — Node.js の例:

# .circleci/config.yml
version: 2.1

orbs:
  node: circleci/node@5

jobs:
  lint-and-test:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - node/install-packages
      - run: npm run lint
      - run: npm test -- --coverage
      - store_test_results:
          path: test-results
      - store_artifacts:
          path: coverage

  build:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - node/install-packages
      - run: npm run build
      - persist_to_workspace:
          root: .
          paths: [dist]

  deploy:
    docker:
      - image: cimg/node:20.11
    steps:
      - attach_workspace:
          at: .
      - run: npx vercel deploy --prod --token $VERCEL_TOKEN

workflows:
  build-and-deploy:
    jobs:
      - lint-and-test
      - build:
          requires: [lint-and-test]
      - deploy:
          requires: [build]
          filters:
            branches:
              only: main

例 1: Docker デプロイメントを使用した Django API 用の GitLab CI

ユーザーリクエスト: "Docker デプロイメントを使用した Django アプリケーション用の GitLab CI パイプラインを作成してください"

実行されたアクション:

  1. 検出: Django 4.2, Poetry, Pytest, PostgreSQL 依存関係
  2. lint, test (Postgres サービスを使用), build, deploy ステージで .gitlab-ci.yml を作成
  3. 統合テスト用に Postgres サービスコンテナを追加
  4. Docker イメージのビルドと GitLab Container Registry へのプッシュを設定

結果:

作成: .gitlab-ci.yml
ステージ: lint -> test -> build -> deploy
- lint: ruff + mypy 型チェック
- test: PostgreSQL 16 サービスコンテナを使用した pytest
- build: Docker イメージのビルド、$CI_REGISTRY_IMAGE にプッシュ
- deploy: 本番環境への SSH デプロイ (手動トリガー)
必要な変数: DEPLOY_HOST, DEPLOY_USER, SSH_PRIVATE_KEY

例 2: Node.js モノレポ用の CircleCI

ユーザーリクエスト: "パッケージごとに個別のテストジョブがあるモノレポ用に CircleCI をセットアップしてください"

実行されたアクション:

  1. 検出: 3 つのパッケージ (api, web, shared) を持つ pnpm ワークスペース
  2. パッケージごとに並列テストジョブで .circleci/config.yml を作成
  3. 変更されたパッケージのジョブのみを実行するために、パスフィルタリングを使用
  4. web パッケージのビルドとデプロイのワークフローを追加

結果:

作成: .circleci/config.yml
ジョブ: test-api, test-web, test-shared, build-web, deploy-web
- パスフィルタリングを使用: 変更されたパッケージのみをテスト
- ジョブ間で共有される依存関係のキャッシュ
- main ブランチでのみ Vercel にデプロイ
必要な環境変数: VERCEL_TOKEN
推定実行時間: ~4 分 (並列ジョブ)

ガイドライン

  • 実行を高速化するために、依存関係のキャッシュを有効にします。GitLab は cache: ブロックを使用します。CircleCI は orb または save_cache/restore_cache を使用します。
  • ジョブにインストールするのではなく、データベーステスト (Postgres, Redis など) にサービスコンテナを使用します。
  • CI (すべてのプッシュ/MR で実行) を CD (main/tags でのみ実行) から分離します。
  • シークレットは CI/CD 変数に保存し、パイプラインファイルには絶対に保存しないでください。
  • GitLab CI では only/rules を、CircleCI では filters を使用します。

(原文がここで切り詰められています)

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

CI/CD Pipeline (GitLab CI & CircleCI)

Overview

Generate production-ready CI/CD pipeline configurations for automated testing, building, and deploying applications on GitLab CI and CircleCI. This skill creates well-structured workflows with proper caching, matrix testing, environment separation, and deployment strategies. For GitHub Actions pipelines, use the github-actions skill.

Instructions

When a user asks to create or improve a CI/CD pipeline, follow these steps:

Step 1: Analyze the project

Detect the project type and requirements:

# Determine language and framework
ls package.json pyproject.toml Gemfile go.mod Cargo.toml pom.xml build.gradle 2>/dev/null

# Check for existing CI config
ls .gitlab-ci.yml .circleci/config.yml 2>/dev/null

# Detect test commands
cat package.json | grep -A5 '"scripts"' 2>/dev/null
cat Makefile 2>/dev/null | grep -E "^test|^lint|^build"

Identify:

  • Language/runtime: Node.js, Python, Go, Rust, Java
  • Package manager: npm, pnpm, yarn, pip, poetry
  • Test framework: Jest, Pytest, Go test, etc.
  • Build output: Docker image, static site, binary, package
  • Deploy target: AWS, Docker registry, npm registry, SSH server

Step 2: Choose the CI/CD platform

Default to GitLab CI if the repo is on GitLab. Use CircleCI if specified or if the project already has a .circleci/ directory.

Step 3: Generate the pipeline configuration

GitLab CI — Node.js example:

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"

.node-cache:
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

lint:
  stage: lint
  extends: .node-cache
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  extends: .node-cache
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm test -- --coverage
  coverage: '/All files.*\|.*\s+([\d\.]+)/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

build:
  stage: build
  extends: .node-cache
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
  only:
    - main

GitLab CI — Docker build and deploy:

build-image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - main

deploy:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
  script:
    - ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$DEPLOY_HOST "docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA && docker-compose up -d"
  when: manual
  only:
    - main

CircleCI — Node.js example:

# .circleci/config.yml
version: 2.1

orbs:
  node: circleci/node@5

jobs:
  lint-and-test:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - node/install-packages
      - run: npm run lint
      - run: npm test -- --coverage
      - store_test_results:
          path: test-results
      - store_artifacts:
          path: coverage

  build:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - node/install-packages
      - run: npm run build
      - persist_to_workspace:
          root: .
          paths: [dist]

  deploy:
    docker:
      - image: cimg/node:20.11
    steps:
      - attach_workspace:
          at: .
      - run: npx vercel deploy --prod --token $VERCEL_TOKEN

workflows:
  build-and-deploy:
    jobs:
      - lint-and-test
      - build:
          requires: [lint-and-test]
      - deploy:
          requires: [build]
          filters:
            branches:
              only: main

Examples

Example 1: GitLab CI for a Django API with Docker deployment

User request: "Create a GitLab CI pipeline for my Django app with Docker deployment"

Actions taken:

  1. Detected: Django 4.2, Poetry, Pytest, PostgreSQL dependency
  2. Created .gitlab-ci.yml with lint, test (with Postgres service), build, deploy stages
  3. Added Postgres service container for integration tests
  4. Configured Docker image build and push to GitLab Container Registry

Result:

Created: .gitlab-ci.yml
Stages: lint -> test -> build -> deploy
- lint: ruff + mypy type checking
- test: pytest with PostgreSQL 16 service container
- build: Docker image build, pushed to $CI_REGISTRY_IMAGE
- deploy: SSH deploy to production (manual trigger)
Required variables: DEPLOY_HOST, DEPLOY_USER, SSH_PRIVATE_KEY

Example 2: CircleCI for a Node.js monorepo

User request: "Set up CircleCI for my monorepo with separate test jobs per package"

Actions taken:

  1. Detected: pnpm workspace with 3 packages (api, web, shared)
  2. Created .circleci/config.yml with parallel test jobs per package
  3. Used path filtering to only run jobs for changed packages
  4. Added build and deploy workflow for the web package

Result:

Created: .circleci/config.yml
Jobs: test-api, test-web, test-shared, build-web, deploy-web
- Uses path filtering: only tests changed packages
- Shared dependency caching across jobs
- Deploy to Vercel on main branch only
Required env vars: VERCEL_TOKEN
Estimated run time: ~4 minutes (parallel jobs)

Guidelines

  • Enable dependency caching to speed up runs. GitLab uses cache: blocks; CircleCI uses orbs or save_cache/restore_cache.
  • Use service containers for database tests (Postgres, Redis, etc.) rather than installing them in the job.
  • Separate CI (runs on every push/MR) from CD (runs only on main/tags).
  • Store secrets in CI/CD variables, never in pipeline files.
  • Use only/rules in GitLab CI or filters in CircleCI to control when jobs run.
  • For monorepos, use path-based triggers to only run relevant pipelines.
  • GitLab CI supports extends and YAML anchors for DRY configs — use them for shared job configurations.
  • CircleCI orbs encapsulate common patterns (Node, Python, Docker) — prefer orbs over manual setup.
  • Add when: manual in GitLab CI or approval jobs in CircleCI for production deploys to prevent accidental releases.