ぱんだツールズぱんだツールズ無料

CI/CD設定構文 横断比較

GitHub Actions・GitLab CI・CircleCI・AWS CodeBuildの構文を「やりたいこと」で逆引き比較

ぱんだツールズファイルはサーバーに送信されません

カテゴリ

重要度

表示するサービス

28 件のパターン

トリガー・起動条件必須

コードをpushしたときに自動でパイプラインを実行する

#push#トリガー#自動実行#基本
GitHub Actions.github/workflows/ci.yml
on:
  push:
    branches:
      - main
      - develop
GitLab CI.gitlab-ci.yml
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

# または特定ブランチのみ
only:
  - main
  - develop
CircleCI.circleci/config.yml
workflows:
  build:
    jobs:
      - test:
          filters:
            branches:
              only:
                - main
                - develop
AWS CodeBuildbuildspec.yml
# CodePipeline側でトリガーを設定
# buildspec.yml はビルド設定のみ記述
version: 0.2
phases:
  build:
    commands:
      - echo "Build started"

⚠ 注意:CodeBuild単体ではなくCodePipelineでトリガー設定を行う

公式ドキュメント
トリガー・起動条件必須

プルリクエスト(MR)の作成・更新時にパイプラインを実行する

#PR#pull request#merge request#トリガー
GitHub Actions.github/workflows/ci.yml
on:
  pull_request:
    branches:
      - main
    types:
      - opened
      - synchronize
      - reopened
GitLab CI.gitlab-ci.yml
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# ジョブレベルでの指定
job-name:
  only:
    - merge_requests

⚠ 注意:GitLabはMerge Request(MR)と呼ぶ

公式ドキュメント
CircleCI.circleci/config.yml
workflows:
  build:
    jobs:
      - test:
          filters:
            branches:
              ignore: main

⚠ 注意:CircleCIはPR専用トリガーはない。GitHub側のブランチ保護で代替

公式ドキュメント
AWS CodeBuildCloudFormation / AWS Console
# GitHub連携の場合はCodePipelineで設定
# WebhookをPRイベントに限定
FilterGroups:
  - - Type: EVENT
      Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
トリガー・起動条件よく使う

スケジュール(cron式)で定期的にパイプラインを実行する

#cron#スケジュール#定期実行#夜間バッチ
GitHub Actions.github/workflows/schedule.yml
on:
  schedule:
    # 毎日 JST 9:00 (UTC 0:00)
    - cron: '0 0 * * *'

⚠ 注意:タイムゾーンはUTC固定。JSTは-9時間で計算する

公式ドキュメント
GitLab CI.gitlab-ci.yml(UI設定との組み合わせ)
# UIから設定: Settings → CI/CD → Schedules
# または .gitlab-ci.yml で変数を使って条件分岐
job-name:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
CircleCI.circleci/config.yml
# .circleci/config.yml に追加
schedules:
  nightly:
    cron: "0 0 * * *"
    filters:
      branches:
        only:
          - main

⚠ 注意:CircleCI v2.1以降で利用可能

公式ドキュメント
AWS CodeBuildAWS EventBridge コンソール / CloudFormation
# EventBridge (CloudWatch Events) でスケジュール設定
# rate形式
rate(1 day)
# cron形式(UTC)
cron(0 0 * * ? *)
トリガー・起動条件よく使う

手動でパイプラインを実行できるようにする(UIからの起動)

#手動#manual#dispatch#ワークフロー手動実行
GitHub Actions.github/workflows/deploy.yml
on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ環境'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production
GitLab CI.gitlab-ci.yml
# UIの「Run pipeline」ボタンで手動実行可能
# 変数を渡す場合
variables:
  DEPLOY_ENV:
    value: "staging"
    description: "デプロイ環境"
CircleCI.circleci/config.yml
# CircleCI UIから「Trigger Pipeline」で手動実行
# パラメーターを渡す場合
parameters:
  deploy-env:
    type: string
    default: "staging"
AWS CodeBuildAWS CLI / コンソール
# AWS CLIで手動実行
aws codebuild start-build   --project-name my-project   --environment-variables-override     name=DEPLOY_ENV,value=staging,type=PLAINTEXT
トリガー・起動条件よく使う

タグをpushしたときにリリースパイプラインを実行する

#tag#タグ#リリース#バージョン
GitHub Actions.github/workflows/release.yml
on:
  push:
    tags:
      - 'v*.*.*'
GitLab CI.gitlab-ci.yml
job-name:
  only:
    - tags
  # または
  rules:
    - if: $CI_COMMIT_TAG
CircleCI.circleci/config.yml
workflows:
  release:
    jobs:
      - deploy:
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/

⚠ 注意:CircleCIはタグトリガー時にbranchesのignoreも明示する必要がある

公式ドキュメント
AWS CodeBuildAWS Console / CloudFormation
# Webhookフィルターでタグpushに限定
FilterGroups:
  - - Type: EVENT
      Pattern: PUSH
    - Type: HEAD_REF
      Pattern: ^refs/tags/v.*
ジョブ定義必須

基本的なジョブを定義してコマンドを実行する

#ジョブ#基本#run#steps
GitHub Actions.github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
GitLab CI.gitlab-ci.yml
build:
  image: node:20
  script:
    - npm ci
    - npm test
CircleCI.circleci/config.yml
jobs:
  build:
    docker:
      - image: cimg/node:20.0
    steps:
      - checkout
      - run:
          name: Install dependencies
          command: npm ci
      - run:
          name: Run tests
          command: npm test
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 20
  pre_build:
    commands:
      - npm ci
  build:
    commands:
      - npm test
ジョブ定義よく使う

複数のジョブを並列で実行してビルド時間を短縮する

#並列#parallel#高速化#ジョブ
GitHub Actions.github/workflows/ci.yml
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  type-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run type-check

⚠ 注意:依存関係を指定しなければ全ジョブが並列実行される

公式ドキュメント
GitLab CI.gitlab-ci.yml
stages:
  - check

lint:
  stage: check
  script: npm run lint

test:
  stage: check
  script: npm test

type-check:
  stage: check
  script: npm run type-check

⚠ 注意:同じstageに属するジョブは並列実行される

公式ドキュメント
CircleCI.circleci/config.yml
workflows:
  build:
    jobs:
      - lint
      - test
      - type-check

⚠ 注意:依存関係(requires)を指定しなければ並列実行

公式ドキュメント
AWS CodeBuildAWS CodePipeline コンソール / CloudFormation
# CodePipeline でステージ内に複数のActionを並列配置
# buildspec.yml の build フェーズは並列実行不可
# 並列化はCodePipeline側のAction設定で行う

⚠ 注意:buildspec.yml単体での並列化は限定的。CodePipelineで複数Actionを並列配置する

公式ドキュメント
ジョブ定義よく使う

ジョブに依存関係を設定してテスト後にデプロイを実行する

#依存関係#needs#requires#順序
GitHub Actions.github/workflows/ci.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run deploy
GitLab CI.gitlab-ci.yml
stages:
  - test
  - deploy

test:
  stage: test
  script: npm test

deploy:
  stage: deploy
  script: npm run deploy
  needs: [test]

⚠ 注意:needsを使うとステージ順序を待たず依存ジョブ完了次第開始できる

公式ドキュメント
CircleCI.circleci/config.yml
workflows:
  build-deploy:
    jobs:
      - test
      - deploy:
          requires:
            - test
AWS CodeBuildAWS CodePipeline コンソール / CloudFormation
# CodePipeline でステージを順番に定義
# Stage1: Test → Stage2: Deploy
# 前のステージが成功しないと次に進まない
ジョブ定義よく使う

ジョブのタイムアウト時間を設定して無限待機を防ぐ

#タイムアウト#timeout#無限ループ防止
GitHub Actions.github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
      - run: npm test

⚠ 注意:デフォルトは360分(6時間)。意図しない長時間実行でクレジットを消費しないよう設定推奨

公式ドキュメント
GitLab CI.gitlab-ci.yml
job-name:
  script: npm test
  timeout: 30 minutes
  # または
  # timeout: 1h 30m
CircleCI.circleci/config.yml
jobs:
  build:
    docker:
      - image: cimg/node:20.0
    steps:
      - run:
          name: Run tests
          command: npm test
          no_output_timeout: 30m

⚠ 注意:no_output_timeoutは出力がない場合のタイムアウト。全体のタイムアウトはUIで設定

公式ドキュメント
AWS CodeBuildbuildspec.yml / AWS プロジェクト設定
version: 0.2
# buildspec.yml ではなくプロジェクト設定でタイムアウトを指定
# AWS CLI:
# aws codebuild update-project #   --name my-project #   --timeout-in-minutes 30

⚠ 注意:タイムアウトはプロジェクト設定で指定(5〜480分)

公式ドキュメント
キャッシュ・高速化必須

Node.jsのnode_modulesをキャッシュしてnpm installを高速化する

#キャッシュ#Node.js#npm#yarn#高速化
GitHub Actions.github/workflows/ci.yml
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-
- run: npm ci

⚠ 注意:hashFilesのパスはワークスペースルート基準。node_modulesよりも~/.npmをキャッシュするのが推奨

公式ドキュメント
GitLab CI.gitlab-ci.yml
job-name:
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - node_modules/
    policy: pull-push
  script:
    - npm ci
CircleCI.circleci/config.yml
steps:
  - restore_cache:
      keys:
        - v1-deps-{{ checksum "package-lock.json" }}
        - v1-deps-
  - run: npm ci
  - save_cache:
      key: v1-deps-{{ checksum "package-lock.json" }}
      paths:
        - node_modules

⚠ 注意:save_cacheは同じキーでは上書きされない。キーを変更したい場合は v1- のプレフィックスを更新する

公式ドキュメント
AWS CodeBuildbuildspec.yml
version: 0.2
cache:
  paths:
    - 'node_modules/**/*'
phases:
  install:
    commands:
      - npm ci

⚠ 注意:S3キャッシュが必要な場合はプロジェクト設定でS3バケットを指定する

公式ドキュメント
キャッシュ・高速化よく使う

Pythonのpipパッケージをキャッシュしてインストールを高速化する

#キャッシュ#Python#pip#pipenv#poetry#高速化
GitHub Actions.github/workflows/ci.yml
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'
- run: pip install -r requirements.txt

⚠ 注意:setup-python の cache オプションで自動キャッシュ。pip / pipenv / poetry に対応

公式ドキュメント
GitLab CI.gitlab-ci.yml
job-name:
  image: python:3.12
  cache:
    paths:
      - .cache/pip
  variables:
    PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
  script:
    - pip install -r requirements.txt
CircleCI.circleci/config.yml
steps:
  - restore_cache:
      keys:
        - pip-{{ checksum "requirements.txt" }}
  - run: pip install -r requirements.txt
  - save_cache:
      key: pip-{{ checksum "requirements.txt" }}
      paths:
        - ~/.cache/pip
AWS CodeBuildbuildspec.yml
version: 0.2
cache:
  paths:
    - '/root/.cache/pip/**/*'
phases:
  install:
    runtime-versions:
      python: 3.12
    commands:
      - pip install -r requirements.txt
キャッシュ・高速化よく使う

Dockerイメージのレイヤーをキャッシュしてビルド時間を短縮する

#Docker#キャッシュ#レイヤーキャッシュ#高速化
GitHub Actions.github/workflows/docker.yml
- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push
  uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max
    push: true
    tags: myapp:latest

⚠ 注意:GitHub Actions Cache backend(type=gha)を使うとキャッシュが自動管理される

公式ドキュメント
GitLab CI.gitlab-ci.yml
build:
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_BUILDKIT: 1
  script:
    - docker buildx build
        --cache-from type=registry,ref=$CI_REGISTRY_IMAGE:cache
        --cache-to type=registry,ref=$CI_REGISTRY_IMAGE:cache,mode=max
        --push
        -t $CI_REGISTRY_IMAGE:latest .
CircleCI.circleci/config.yml
- restore_cache:
    keys:
      - docker-{{ .Branch }}-{{ checksum "Dockerfile" }}
- run: docker build -t myapp .
- save_cache:
    key: docker-{{ .Branch }}-{{ checksum "Dockerfile" }}
    paths:
      - /tmp/docker-cache

⚠ 注意:Docker Layer Caching(DLC)はCircleCI有料プランの機能

公式ドキュメント
AWS CodeBuildbuildspec.yml
# プロジェクト設定でDockerレイヤーキャッシュを有効化
# buildspec.yml:
version: 0.2
phases:
  pre_build:
    commands:
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
  build:
    commands:
      - docker buildx build --cache-from $ECR_REGISTRY/myapp:cache -t myapp .

⚠ 注意:CodeBuild のDocker Layer Cachingは追加料金なしで利用可能(設定で有効化)

公式ドキュメント
環境変数・シークレット必須

環境変数を定義してビルド・テストで参照する

#環境変数#env#変数
GitHub Actions.github/workflows/ci.yml
env:
  NODE_ENV: production
  API_VERSION: v2

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      BUILD_MODE: release  # ジョブレベルの変数
    steps:
      - run: echo "Node env is $NODE_ENV"
GitLab CI.gitlab-ci.yml
variables:
  NODE_ENV: production
  API_VERSION: v2

job-name:
  variables:
    BUILD_MODE: release  # ジョブレベルの変数
  script:
    - echo "Node env is $NODE_ENV"
CircleCI.circleci/config.yml
jobs:
  build:
    docker:
      - image: cimg/node:20.0
    environment:
      NODE_ENV: production
      API_VERSION: v2
    steps:
      - run: echo "Node env is $NODE_ENV"
AWS CodeBuildbuildspec.yml
version: 0.2
env:
  variables:
    NODE_ENV: production
    API_VERSION: v2
phases:
  build:
    commands:
      - echo "Node env is $NODE_ENV"
環境変数・シークレット必須

APIキーやパスワードなどのシークレットを安全に参照する

#シークレット#secrets#API key#セキュリティ
GitHub Actions.github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        env:
          API_KEY: ${{ secrets.API_KEY }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: ./deploy.sh

⚠ 注意:Secretsはリポジトリ設定 → Secrets and variables から登録。ログに出力されてもマスクされる

公式ドキュメント
GitLab CI.gitlab-ci.yml
# UIで設定: Settings → CI/CD → Variables → Add variable (Masked: ON)
deploy:
  script:
    - echo "Deploying with key $API_KEY"
    - ./deploy.sh
  # シークレット変数は自動で参照可能(定義不要)

⚠ 注意:Maskedにするとログ出力されない。Protectedにすると保護ブランチのみ参照可能

公式ドキュメント
CircleCI.circleci/config.yml
# Project Settings → Environment Variables に登録
# buildspec.yml では $変数名 で参照
jobs:
  deploy:
    docker:
      - image: cimg/base:stable
    steps:
      - run: echo "API_KEY=$API_KEY" >> .env
AWS CodeBuildbuildspec.yml
version: 0.2
env:
  secrets-manager:
    API_KEY: arn:aws:secretsmanager:ap-northeast-1:123456789:secret:my-secret:API_KEY
  parameter-store:
    DB_PASSWORD: /myapp/db-password
phases:
  build:
    commands:
      - echo "Deploying with $API_KEY"

⚠ 注意:Secrets ManagerまたはParameter Store(SecureString)との統合が推奨

公式ドキュメント
環境変数・シークレットよく使う

staging / production などデプロイ環境ごとに変数を切り替える

#環境#staging#production#環境変数#切り替え
GitHub Actions.github/workflows/deploy.yml
jobs:
  deploy-staging:
    environment: staging
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh
        env:
          API_URL: ${{ vars.API_URL }}  # 環境変数(非シークレット)
          API_KEY: ${{ secrets.API_KEY }}  # 環境シークレット

  deploy-production:
    environment: production
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh
        env:
          API_URL: ${{ vars.API_URL }}
          API_KEY: ${{ secrets.API_KEY }}

⚠ 注意:Environmentsを使うと環境ごとにSecretsを分離できる。productionには承認ゲートも設定可能

公式ドキュメント
GitLab CI.gitlab-ci.yml
deploy-staging:
  script: ./deploy.sh
  environment:
    name: staging
  variables:
    API_URL: https://staging.example.com

deploy-production:
  script: ./deploy.sh
  environment:
    name: production
  variables:
    API_URL: https://example.com
  when: manual
CircleCI.circleci/config.yml
# Contextsを使って環境ごとに変数を分離
workflows:
  deploy:
    jobs:
      - deploy-staging:
          context: staging-context
      - deploy-production:
          context: production-context
          requires:
            - deploy-staging
AWS CodeBuildbuildspec.yml
# Parameter Storeで環境ごとにパスを分ける
# /staging/api-url → https://staging.example.com
# /production/api-url → https://example.com

version: 0.2
env:
  parameter-store:
    API_URL: /${DEPLOY_ENV}/api-url
デプロイよく使う

AWS S3にビルド成果物をデプロイしてCloudFrontのキャッシュを削除する

#AWS#S3#CloudFront#デプロイ#静的サイト
GitHub Actions.github/workflows/deploy.yml
- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ap-northeast-1

- name: Deploy to S3
  run: aws s3 sync ./dist s3://my-bucket --delete

- name: Invalidate CloudFront
  run: |
    aws cloudfront create-invalidation       --distribution-id ${{ secrets.CF_DISTRIBUTION_ID }}       --paths "/*"
GitLab CI.gitlab-ci.yml
deploy:
  image: amazon/aws-cli
  script:
    - aws s3 sync ./dist s3://$S3_BUCKET --delete
    - aws cloudfront create-invalidation
        --distribution-id $CF_DISTRIBUTION_ID
        --paths "/*"
  variables:
    AWS_DEFAULT_REGION: ap-northeast-1

⚠ 注意:AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYはCI/CD変数に登録しておく

公式ドキュメント
CircleCI.circleci/config.yml
- run:
    name: Deploy to S3
    command: |
      aws s3 sync ./dist s3://$S3_BUCKET --delete
      aws cloudfront create-invalidation         --distribution-id $CF_DISTRIBUTION_ID         --paths "/*"
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  build:
    commands:
      - npm run build
  post_build:
    commands:
      - aws s3 sync ./dist s3://$S3_BUCKET --delete
      - aws cloudfront create-invalidation
          --distribution-id $CF_DISTRIBUTION_ID
          --paths "/*"

⚠ 注意:CodeBuildのサービスロールにS3とCloudFrontの権限を付与する

公式ドキュメント
デプロイよく使う

Next.js / フロントエンドプロジェクトをVercelにデプロイする

#Vercel#Next.js#デプロイ#フロントエンド
GitHub Actions.github/workflows/deploy.yml
- name: Deploy to Vercel
  uses: amondnet/vercel-action@v25
  with:
    vercel-token: ${{ secrets.VERCEL_TOKEN }}
    vercel-org-id: ${{ secrets.ORG_ID }}
    vercel-project-id: ${{ secrets.PROJECT_ID }}
    vercel-args: '--prod'  # 本番デプロイ(省略するとプレビュー)

⚠ 注意:GitHubリポジトリをVercelに接続すると自動デプロイも設定可能

公式ドキュメント
GitLab CI.gitlab-ci.yml
deploy:
  image: node:20
  script:
    - npm i -g vercel
    - vercel --token $VERCEL_TOKEN --prod
CircleCI.circleci/config.yml
- run:
    name: Deploy to Vercel
    command: |
      npm i -g vercel
      vercel --token $VERCEL_TOKEN --prod
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  install:
    commands:
      - npm install -g vercel
  build:
    commands:
      - npm run build
  post_build:
    commands:
      - vercel --token $VERCEL_TOKEN --prod

⚠ 注意:VercelトークンはParameter StoreまたはSecrets Managerに保存する

公式ドキュメント
デプロイよく使う

DockerイメージをビルドしてDocker Hubにpushする

#Docker#Docker Hub#push#コンテナ
GitHub Actions.github/workflows/docker.yml
- uses: docker/login-action@v3
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

- uses: docker/build-push-action@v5
  with:
    push: true
    tags: |
      myuser/myapp:latest
      myuser/myapp:${{ github.sha }}
GitLab CI.gitlab-ci.yml
build-push:
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker login -u $DOCKERHUB_USER -p $DOCKERHUB_TOKEN
    - docker build -t $DOCKERHUB_USER/myapp:$CI_COMMIT_SHA .
    - docker tag $DOCKERHUB_USER/myapp:$CI_COMMIT_SHA $DOCKERHUB_USER/myapp:latest
    - docker push $DOCKERHUB_USER/myapp:$CI_COMMIT_SHA
    - docker push $DOCKERHUB_USER/myapp:latest
CircleCI.circleci/config.yml
- run:
    name: Build and push Docker image
    command: |
      echo "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USER" --password-stdin
      docker build -t $DOCKERHUB_USER/myapp:$CIRCLE_SHA1 .
      docker push $DOCKERHUB_USER/myapp:$CIRCLE_SHA1
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  pre_build:
    commands:
      - echo "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USER" --password-stdin
  build:
    commands:
      - docker build -t $DOCKERHUB_USER/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION .
  post_build:
    commands:
      - docker push $DOCKERHUB_USER/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION
      - docker tag $DOCKERHUB_USER/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION $DOCKERHUB_USER/myapp:latest
      - docker push $DOCKERHUB_USER/myapp:latest
デプロイよく使う

DockerイメージをAmazon ECRにpushしてECS/EKSで利用する

#AWS#ECR#ECS#Docker#コンテナ
GitHub Actions.github/workflows/deploy.yml
- uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ap-northeast-1

- id: login-ecr
  uses: aws-actions/amazon-ecr-login@v2

- uses: docker/build-push-action@v5
  with:
    push: true
    tags: ${{ steps.login-ecr.outputs.registry }}/myapp:${{ github.sha }}
GitLab CI.gitlab-ci.yml
build-ecr:
  image: amazon/aws-cli
  services:
    - docker:24-dind
  script:
    - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
    - docker build -t $ECR_REGISTRY/myapp:$CI_COMMIT_SHA .
    - docker push $ECR_REGISTRY/myapp:$CI_COMMIT_SHA
CircleCI.circleci/config.yml
- run:
    name: Push to ECR
    command: |
      aws ecr get-login-password --region ap-northeast-1 |         docker login --username AWS --password-stdin $ECR_REGISTRY
      docker build -t $ECR_REGISTRY/myapp:$CIRCLE_SHA1 .
      docker push $ECR_REGISTRY/myapp:$CIRCLE_SHA1
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  pre_build:
    commands:
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION |
          docker login --username AWS --password-stdin $ECR_REGISTRY
  build:
    commands:
      - docker build -t $ECR_REGISTRY/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION .
  post_build:
    commands:
      - docker push $ECR_REGISTRY/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION
      - printf '[{"name":"myapp","imageUri":"%s"}]' $ECR_REGISTRY/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION > imagedefinitions.json
artifacts:
  files: imagedefinitions.json

⚠ 注意:imagedefinitions.jsonをアーティファクトとして出力するとCodeDeployでECSデプロイに使える

公式ドキュメント
Docker必須

Dockerfileからイメージをビルドしてタグを付ける

#Docker#build#Dockerfile#イメージ
GitHub Actions.github/workflows/ci.yml
- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build Docker image
  uses: docker/build-push-action@v5
  with:
    context: .
    push: false
    tags: myapp:${{ github.sha }}
    load: true
GitLab CI.gitlab-ci.yml
build:
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_BUILDKIT: 1
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
CircleCI.circleci/config.yml
jobs:
  build:
    machine:
      image: ubuntu-2204:current
    steps:
      - checkout
      - run: docker build -t myapp:$CIRCLE_SHA1 .

⚠ 注意:machine executorを使うとDocker-in-Dockerが不要

公式ドキュメント
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  build:
    commands:
      - docker build -t myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION .

⚠ 注意:プロジェクト設定でPrivilegedモードを有効にする必要がある

公式ドキュメント
Dockerよく使う

docker-composeでDBなどの依存サービスを起動してE2Eテストを実行する

#docker-compose#E2E#データベース#サービス依存
GitHub Actions.github/workflows/e2e.yml
services:
  postgres:
    image: postgres:16
    env:
      POSTGRES_PASSWORD: postgres
    options: >-
      --health-cmd pg_isready
      --health-interval 10s
      --health-timeout 5s
      --health-retries 5
    ports:
      - 5432:5432

steps:
  - run: npm run test:e2e
    env:
      DATABASE_URL: postgres://postgres:postgres@localhost:5432/test
GitLab CI.gitlab-ci.yml
test-e2e:
  image: node:20
  services:
    - name: postgres:16
      alias: postgres
  variables:
    POSTGRES_PASSWORD: postgres
    DATABASE_URL: postgres://postgres:postgres@postgres:5432/test
  script:
    - npm run test:e2e
CircleCI.circleci/config.yml
jobs:
  test-e2e:
    docker:
      - image: cimg/node:20.0
      - image: postgres:16
        environment:
          POSTGRES_PASSWORD: postgres
    environment:
      DATABASE_URL: postgres://postgres:postgres@localhost:5432/test
    steps:
      - checkout
      - run: npm run test:e2e
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  pre_build:
    commands:
      - docker-compose up -d db
      - sleep 10  # DB起動待機
  build:
    commands:
      - DATABASE_URL=postgres://postgres:postgres@localhost:5432/test npm run test:e2e
  post_build:
    commands:
      - docker-compose down

⚠ 注意:Privilegedモードの有効化が必要

公式ドキュメント
マトリクスビルドよく使う

複数のNode.jsバージョンで並列テストして互換性を確認する

#マトリクス#matrix#Node.js#バージョン#互換性
GitHub Actions.github/workflows/ci.yml
jobs:
  test:
    strategy:
      matrix:
        node-version: [18, 20, 22]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci && npm test
GitLab CI.gitlab-ci.yml
test:
  image: node:$NODE_VERSION
  parallel:
    matrix:
      - NODE_VERSION: ['18', '20', '22']
  script:
    - npm ci
    - npm test
CircleCI.circleci/config.yml
# CircleCIにはネイティブのmatrixはない
# parameters で代替
parameters:
  node-version:
    type: string
    default: "20"

jobs:
  test:
    docker:
      - image: cimg/node:<< pipeline.parameters.node-version >>
    steps:
      - checkout
      - run: npm ci && npm test

⚠ 注意:CircleCIでの複数バージョンテストはmatrix strategyがなくworkflow + parametersで代替

公式ドキュメント
AWS CodeBuild(非対応)
# CodeBuildにはmatrixビルドがない
# 複数プロジェクトを並列実行する方法か
# Lambda + Step Functionsで制御する方法がある

⚠ 注意:Batch Buildを使えば複数設定を並列実行できるが、完全なmatrix strategyは非対応

公式ドキュメント
マトリクスビルド応用

Windows / macOS / Linux の複数OSで並列テストしてクロスプラットフォーム互換性を確認する

#マトリクス#OS#Windows#macOS#Linux#クロスプラットフォーム
GitHub Actions.github/workflows/ci.yml
jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
GitLab CI.gitlab-ci.yml
# GitLab SaaSのShared Runnerは主にLinux
# macOS/Windowsは有料またはセルフホストRunnerが必要
test-linux:
  image: node:20
  script: npm ci && npm test

test-windows:
  tags:
    - windows
  script:
    - npm ci
    - npm test

⚠ 注意:macOS/Windowsランナーは追加設定が必要

公式ドキュメント
CircleCI.circleci/config.yml
jobs:
  test-linux:
    docker:
      - image: cimg/node:20.0
    steps:
      - checkout
      - run: npm ci && npm test

  test-macos:
    macos:
      xcode: "15.0"
    steps:
      - checkout
      - run: node --version && npm ci && npm test

⚠ 注意:macOSはCircleCI有料プランの機能

公式ドキュメント
AWS CodeBuildCloudFormation / AWS Console
# CodeBuildはLinux / Windows / macOS に対応
# 環境ごとに別プロジェクトを作成して並列実行
# 環境の指定(CloudFormation):
# Environment:
#   Type: LINUX_CONTAINER / WINDOWS_SERVER_2019_CONTAINER / MAC_ARM
条件分岐よく使う

ブランチ名によってジョブの実行・スキップを切り替える

#条件#ブランチ#if#when#スキップ
GitHub Actions.github/workflows/deploy.yml
jobs:
  deploy:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production"

  preview:
    if: startsWith(github.ref, 'refs/heads/feature/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying preview"
GitLab CI.gitlab-ci.yml
deploy-prod:
  script: ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-preview:
  script: ./deploy.sh preview
  rules:
    - if: $CI_COMMIT_BRANCH =~ /^feature//
CircleCI.circleci/config.yml
workflows:
  build-deploy:
    jobs:
      - deploy-prod:
          filters:
            branches:
              only: main
      - deploy-preview:
          filters:
            branches:
              only: /^feature/.*/
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  build:
    commands:
      - |
        if [ "$CODEBUILD_WEBHOOK_BASE_REF" = "refs/heads/main" ]; then
          ./deploy.sh production
        else
          ./deploy.sh preview
        fi

⚠ 注意:CODEBUILD_WEBHOOK_BASE_REFはWebhookトリガー時のみ設定される

公式ドキュメント
条件分岐よく使う

本番デプロイ前に手動承認ゲートを設けて意図しないデプロイを防ぐ

#承認#approval#手動#gate#本番
GitHub Actions.github/workflows/deploy.yml
jobs:
  deploy-production:
    environment: production  # Environmentに承認ルールを設定
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh production

⚠ 注意:リポジトリ設定のEnvironmentsで「Required reviewers」を追加するとUIで承認が必要になる

公式ドキュメント
GitLab CI.gitlab-ci.yml
deploy-production:
  script: ./deploy.sh production
  when: manual  # UIで「▶ Run」ボタンを押すまで実行されない
  environment: production
CircleCI.circleci/config.yml
workflows:
  deploy:
    jobs:
      - hold:
          type: approval  # UIで承認するまでブロック
      - deploy-production:
          requires:
            - hold
AWS CodeBuildAWS CodePipeline コンソール / CloudFormation
# CodePipelineのManual Approvalアクションで実現
# ステージ間にApprovalアクションを挿入
# SNS通知でメール/Slackに承認依頼を送信できる
条件分岐よく使う

ビルド・テストが失敗したときだけクリーンアップ処理やアラートを実行する

#失敗#failure#cleanup#エラー処理
GitHub Actions.github/workflows/ci.yml
steps:
  - run: npm test

  - name: Cleanup on failure
    if: failure()
    run: |
      echo "Build failed! Cleaning up..."
      ./cleanup.sh

⚠ 注意:failure() / success() / always() / cancelled() が使用可能

公式ドキュメント
GitLab CI.gitlab-ci.yml
test:
  script: npm test
  after_script:
    - |
      if [ "$CI_JOB_STATUS" = "failed" ]; then
        echo "Job failed! Cleaning up..."
        ./cleanup.sh
      fi
CircleCI.circleci/config.yml
steps:
  - run: npm test
  - run:
      name: Cleanup on failure
      command: |
        echo "Cleaning up..."
        ./cleanup.sh
      when: on_fail

⚠ 注意:when: on_fail / on_success / always が使用可能

公式ドキュメント
AWS CodeBuildbuildspec.yml
version: 0.2
phases:
  build:
    commands:
      - npm test
  post_build:
    commands:
      - |
        if [ "$CODEBUILD_BUILD_SUCCEEDING" = "0" ]; then
          echo "Build failed! Cleaning up..."
          ./cleanup.sh
        fi

⚠ 注意:CODEBUILD_BUILD_SUCCEEDING: 成功=1, 失敗=0

公式ドキュメント
通知よく使う

ビルド結果(成功・失敗)をSlackに通知する

#Slack#通知#チャット#アラート
GitHub Actions.github/workflows/ci.yml
- name: Notify Slack
  uses: slackapi/[email protected]
  if: always()
  with:
    payload: |
      {
        "text": "Build ${{ job.status }}: ${{ github.workflow }} on ${{ github.repository }}",
        "attachments": [{
          "color": "${{ job.status == 'success' && 'good' || 'danger' }}",
          "fields": [{"title": "Branch", "value": "${{ github.ref_name }}", "short": true}]
        }]
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
    SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK
GitLab CI.gitlab-ci.yml
notify-slack:
  image: curlimages/curl
  script:
    - |
      STATUS="成功 ✅"
      COLOR="good"
      if [ "$CI_JOB_STATUS" != "success" ]; then
        STATUS="失敗 ❌"
        COLOR="danger"
      fi
      curl -X POST $SLACK_WEBHOOK_URL         -H 'Content-type: application/json'         --data "{"text":"ビルド${STATUS}: ${CI_PROJECT_NAME} (${CI_COMMIT_BRANCH})"}"
  when: always
CircleCI.circleci/config.yml
- slack/notify:
    event: always
    custom: |
      {
        "text": "Build $CIRCLE_JOB",
        "attachments": [{
          "color": "{{ #if failed }}danger{{ else }}good{{ /if }}",
          "text": "$CIRCLE_PROJECT_REPONAME ($CIRCLE_BRANCH)"
        }]
      }

⚠ 注意:circleci/slack Orbを使う。config.yml に orbs: slack: circleci/[email protected] を追加

公式ドキュメント
AWS CodeBuildbuildspec.yml
# CodeBuildのBuild Notificationを使う
# または SNS → Lambda → Slack Webhook
# buildspec.yml に直接書く場合:
version: 0.2
phases:
  post_build:
    commands:
      - |
        STATUS="${CODEBUILD_BUILD_SUCCEEDING:-0}"
        if [ "$STATUS" = "1" ]; then
          MSG="✅ ビルド成功"
        else
          MSG="❌ ビルド失敗"
        fi
        curl -X POST $SLACK_WEBHOOK_URL           -H 'Content-type: application/json'           --data "{"text":"${MSG}: $CODEBUILD_BUILD_ID"}"
通知よく使う

ビルドが失敗したときだけSlack / メールで通知する

#通知#失敗#アラート#Slack#メール
GitHub Actions.github/workflows/ci.yml
- name: Notify Slack on failure
  uses: slackapi/[email protected]
  if: failure()
  with:
    payload: |
      {"text": "❌ ビルド失敗: ${{ github.workflow }} (${{ github.ref_name }})\n${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"}
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
    SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK
GitLab CI.gitlab-ci.yml
notify-failure:
  image: curlimages/curl
  script:
    - |
      curl -X POST $SLACK_WEBHOOK_URL         --data "{"text":"❌ ビルド失敗: $CI_PROJECT_NAME ($CI_COMMIT_BRANCH)"}"
  rules:
    - if: $CI_PIPELINE_SOURCE
      when: on_failure
CircleCI.circleci/config.yml
- slack/notify:
    event: fail
    mentions: '@oncall'
    custom: |
      {"text": "❌ ビルド失敗: $CIRCLE_PROJECT_REPONAME ($CIRCLE_BRANCH)"}
AWS CodeBuildbuildspec.yml / AWS Console
# AWS Developer Toolsの通知ルールを使う
# ビルド失敗イベント → SNS → メール / Slack (Chatbot)
# または buildspec.yml 内で条件判定
version: 0.2
phases:
  post_build:
    commands:
      - |
        if [ "${CODEBUILD_BUILD_SUCCEEDING}" = "0" ]; then
          aws sns publish --topic-arn $SNS_TOPIC_ARN             --message "Build failed: $CODEBUILD_BUILD_ID"
        fi

よくある質問

どのCI/CDサービスに対応していますか?

GitHub Actions・GitLab CI・CircleCI・AWS CodeBuild(+ CodePipeline)の4サービスに対応しています。各サービスの設定ファイルや構文の違いを横断的に比較できます。

「キャッシュ」「デプロイ」など目的から逆引き検索できますか?

はい。検索ボックスにやりたいこと(例:「キャッシュ」「S3」「承認」「Slack」)を入力すると、目的・タグ・コードスニペット内を横断検索します。

GitHub ActionsからGitLab CIに移行したい場合に使えますか?

はい、それがこのツールのメインユースケースの一つです。「push時に実行」「依存関係のキャッシュ」「デプロイ」など各目的で4サービスのコードを並べて比較できるため、移行時の対応表として活用できます。

スニペットはコピーしてそのまま使えますか?

テンプレートとして活用いただけますが、プロジェクト名・シークレット名・リポジトリ設定など環境固有の値は各自で書き換えてください。また、ライブラリのバージョンは最新の公式ドキュメントで確認することをおすすめします。

AWS CodeBuildとAWS CodePipelineの違いは?

CodeBuildはビルド・テスト処理を実行するサービスで、buildspec.ymlで設定します。CodePipelineはCI/CDのパイプライン全体(ソース取得→ビルド→デプロイ)を管理するオーケストレーターです。トリガー設定や承認ゲートはCodePipeline側で行います。

データはどのくらいの頻度で更新されますか?

各CI/CDサービスのメジャーな仕様変更や新機能追加に合わせて定期的に更新しています。公式の最新情報は各スニペットの「公式ドキュメント」リンクからご確認ください。

「注意点」はどういう情報が書いてありますか?

サービス固有の落とし穴(例:GitHub ActionsのhashFilesのパス基準、CircleCIのsave_cacheの上書き不可仕様)、有料プランのみの機能、追加設定が必要な項目などを記載しています。

掲載されていない設定パターンについて要望できますか?

ぱんだツールズのX(旧Twitter)アカウントへご連絡ください。定期更新時に追加を検討します。

開発者ツール一覧

すべて見る

このツールについて

使い方

  1. 検索ボックスにやりたいこと(例:「キャッシュ」「Slackに通知」「本番デプロイ 承認」)を入力
  2. カテゴリボタンで「トリガー・起動条件」「キャッシュ・高速化」「デプロイ」等に絞り込む
  3. 「重要度」フィルターで「必須」を選ぶと特に頻出の設定パターンに絞れる
  4. 「表示するサービス」で移行先・移行元のCI/CDサービスだけを表示して比較する
  5. スニペットの「コピー」ボタンでコードを取得し、プロジェクトに合わせて修正する

このツールの特徴

  • 「やりたいこと」起点の逆引き検索:公式ドキュメントはサービス単位の仕様書だが、このツールは「キャッシュしたい」「Slackに通知したい」という目的から探せる
  • 4サービス横断比較:GitHub Actions・GitLab CI・CircleCI・AWS CodeBuildの同等設定を並べて比較。移行案件の「対応表」として使える
  • 落とし穴・注意点を明記:「CircleCIのsave_cacheは同じキーで上書きされない」「GitHub ActionsのhashFilesはワークスペースルート基準」など、ハマりがちなポイントを記載
  • 日本語ファースト:目的・カテゴリ・注意事項がすべて日本語。英語ドキュメントを読む前のファーストステップとして使える
  • 公式ドキュメントへの直リンク:スニペットごとに公式ドキュメントリンクを掲載。確認・深掘りがすぐにできる

こんなときに便利

  • GitHub ActionsからGitLab CI(またはその逆)に移行するときの構文対応表として
  • 転職・異動で初めて触るCI/CDサービスの設定を素早くキャッチアップしたい
  • 「cronどう書くんだっけ」「マトリクスビルドの構文は?」をすぐに確認したい
  • チームで複数CI/CDを使っていて、設定の統一・標準化を進めたい
  • レビューやペアプロで「他サービスではこう書く」を即確認したい

4サービスの位置づけと選定ポイント

  • GHGitHub Actions:GitHubリポジトリと完全統合。無料枠が充実しており、OSSや個人開発に最適。Marketplaceのアクションエコシステムが最大の強み。
  • GLGitLab CI:GitLabとの完全統合。セルフホスト(GitLab CE/EE)での柔軟な運用が可能。ステージ制の分かりやすいパイプライン設計が特徴。
  • CCCircleCI:独立したCI/CDサービスとしての老舗。Orbsというエコシステムや、macOS/Linux実行環境の豊富な選択肢が強み。
  • AWSAWS CodeBuild + CodePipeline:AWSサービスとの深い統合(ECR・ECS・S3・Lambda等)が最大の強み。IAMロールでの権限管理が自然に組み込める。

仕組み・技術的背景

すべてのデータ(設定パターン・コードスニペット・解説)はブラウザ内に埋め込まれており、 検索・フィルタリングも完全にクライアントサイドで完結します。外部APIへのリクエストは発生しません。 データはTypeScriptのオブジェクトとして管理されており、定期的な保守更新が可能な構造になっています。 YAMLのシンタックスハイライトはCSSのみで実装しており、重いライブラリは使用していません。

注意事項・制限事項

  • スニペットはテンプレートです。プロジェクト名・シークレット名・AWSリソースIDなど環境固有の値は必ず書き換えてください
  • アクションのバージョン(例:actions/cache@v4)は最新バージョンを確認してから使用してください
  • 各CI/CDサービスの仕様は頻繁に更新されます。実際の設定前に公式ドキュメントを必ず確認してください