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本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
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
$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. 下の青いボタンを押して
cicd-pipeline.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
cicd-pipelineフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
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 パイプラインを作成してください"
実行されたアクション:
- 検出: Django 4.2, Poetry, Pytest, PostgreSQL 依存関係
- lint, test (Postgres サービスを使用), build, deploy ステージで
.gitlab-ci.ymlを作成 - 統合テスト用に Postgres サービスコンテナを追加
- 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 をセットアップしてください"
実行されたアクション:
- 検出: 3 つのパッケージ (api, web, shared) を持つ pnpm ワークスペース
- パッケージごとに並列テストジョブで
.circleci/config.ymlを作成 - 変更されたパッケージのジョブのみを実行するために、パスフィルタリングを使用
- 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:
- Detected: Django 4.2, Poetry, Pytest, PostgreSQL dependency
- Created
.gitlab-ci.ymlwith lint, test (with Postgres service), build, deploy stages - Added Postgres service container for integration tests
- 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:
- Detected: pnpm workspace with 3 packages (api, web, shared)
- Created
.circleci/config.ymlwith parallel test jobs per package - Used path filtering to only run jobs for changed packages
- 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 orsave_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/rulesin GitLab CI orfiltersin CircleCI to control when jobs run. - For monorepos, use path-based triggers to only run relevant pipelines.
- GitLab CI supports
extendsand 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: manualin GitLab CI or approval jobs in CircleCI for production deploys to prevent accidental releases.