サイトアイコンmaita tomoya dev io

CI/CD比較

comparison

CI/CD比較(GitHub Actions vs CircleCI vs Jenkins vs AWS CodePipeline)

はじめに

CI/CD(継続的インテグレーション / 継続的デリバリー)は、コードの変更を自動的にビルド・テスト・デプロイするプラクティスである。手動リリースに伴うヒューマンエラーを排除し、リリースサイクルを短縮することで、ソフトウェアの品質と開発速度を両立させる。

本ページでは、現在主流の4つのCI/CDツール — GitHub ActionsCircleCIJenkinsAWS CodePipeline — を比較する。

CI/CDとは

CI(継続的インテグレーション)

開発者がコードを頻繁にメインブランチに統合し、その都度自動でビルド・テストを実行する手法。

CD(継続的デリバリー / デプロイ)

  • 継続的デリバリー: 本番リリース可能な状態を常に維持(リリースは手動承認)
  • 継続的デプロイ: テスト通過後に自動で本番環境にデプロイ
graph LR A[コード変更<br/>git push] --> B[CI: ビルド] B --> C[CI: テスト] C --> D[CI: 静的解析<br/>リント] D --> E{全チェック<br/>通過?} E -->|No| F[失敗通知<br/>修正必要] E -->|Yes| G[CD: ステージング<br/>デプロイ] G --> H{手動承認?} H -->|継続的デリバリー| I[手動承認後<br/>本番デプロイ] H -->|継続的デプロイ| J[自動で<br/>本番デプロイ]

各ツールの誕生背景

ツール登場年開発元背景
Jenkins2011年コミュニティ(元Hudson)オンプレミスCI/CDの草分け。プラグインによる拡張性
CircleCI2011年CircleCI Inc.クラウドネイティブなCI/CD。設定の簡素化
AWS CodePipeline2015年AWSAWSサービスとの統合。マネージドCI/CD
GitHub Actions2019年GitHub (Microsoft)GitHubリポジトリとの統合。YAMLベースのワークフロー

各ツールの全体像

graph TB subgraph GitHub Actions GA1[GitHub リポジトリ] --> GA2[.github/workflows/*.yml] GA2 --> GA3[GitHub-hosted Runner<br/>or Self-hosted Runner] GA3 --> GA4[Marketplace Actions] end subgraph CircleCI CC1[GitHub/Bitbucket] --> CC2[.circleci/config.yml] CC2 --> CC3[CircleCI Cloud<br/>or Self-hosted] CC3 --> CC4[Orbs<br/>再利用可能パッケージ] end subgraph Jenkins JK1[任意のSCM] --> JK2[Jenkinsfile] JK2 --> JK3[Jenkins Server<br/>セルフホスト] JK3 --> JK4[1800+ Plugins] end subgraph AWS CodePipeline CP1[CodeCommit/GitHub] --> CP2[パイプライン定義] CP2 --> CP3[CodeBuild] CP3 --> CP4[CodeDeploy] end

GitHub Actions

概要

GitHub ActionsはGitHubに統合されたCI/CDサービス。リポジトリ内の.github/workflows/にYAMLファイルを配置するだけでワークフローが動作する。

設定例

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ap-northeast-1
      - run: |
          docker build -t my-app .
          docker push $ECR_URI/my-app:latest

メリット

メリット説明
GitHub統合PR、Issue、リリースとシームレスに連携
Marketplace20,000以上の再利用可能なAction
無料枠が充実Public リポジトリは無制限。Privateも2,000分/月(Free)
設定が簡単YAMLベースで直感的
Matrix Build複数の言語バージョン・OSでの並列テストが容易

デメリット

デメリット説明
GitHub依存GitHubから移行する場合にワークフロー書き直し
デバッグが難しいローカルでのテスト実行が困難(act等で部分的に可能)
実行時間制限ジョブ最大6時間、ワークフロー最大35日
同時実行制限Freeプランで20ジョブ同時

CircleCI

概要

CircleCIはクラウドネイティブなCI/CDプラットフォーム。高速なビルドと柔軟なキャッシュ機構が特徴。

設定例

# .circleci/config.yml
version: 2.1

orbs:
  node: circleci/node@5.2.0

jobs:
  test:
    docker:
      - image: cimg/node:20.0
      - image: cimg/postgres:16.0
    steps:
      - checkout
      - node/install-packages
      - run: npm run lint
      - run: npm test
      - store_test_results:
          path: test-results

  deploy:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - setup_remote_docker
      - run: |
          docker build -t my-app .
          docker push $ECR_URI/my-app:latest

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

メリット

メリット説明
高速ビルドDocker Layer Caching、並列実行による高速化
Orbs再利用可能な設定パッケージ。設定の簡素化
柔軟なキャッシュ依存関係のキャッシュが細かく制御可能
SSH デバッグビルド環境にSSH接続してデバッグ可能
Insightsビルド時間、成功率のダッシュボード

デメリット

デメリット説明
料金大規模プロジェクトではGitHub Actionsより高額になりやすい
設定の複雑さ高度な設定は複雑になりがち
GitHub統合の深さGitHub Actionsほどのシームレスな統合はない
サードパーティGitHub/GitLabの追加サービスという位置づけ

Jenkins

概要

Jenkinsはオープンソースの自動化サーバー。自前のサーバーにインストールして運用する。1800以上のプラグインにより、あらゆるCI/CDパイプラインを構築可能。

設定例

// Jenkinsfile (Declarative Pipeline)
pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'npm ci'
                sh 'npm run build'
            }
        }
        stage('Test') {
            parallel {
                stage('Unit Tests') {
                    steps {
                        sh 'npm run test:unit'
                    }
                }
                stage('Integration Tests') {
                    steps {
                        sh 'npm run test:integration'
                    }
                }
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'docker build -t my-app .'
                sh 'docker push $ECR_URI/my-app:latest'
            }
        }
    }

    post {
        failure {
            slackSend(message: "Build Failed: ${env.JOB_NAME}")
        }
    }
}

メリット

メリット説明
完全な制御サーバー、ネットワーク、プラグインを自由に設定
プラグイン1800以上のプラグイン。ほぼ何でも対応可能
オンプレミス対応インターネット非接続環境でも利用可能
無料オープンソース。ライセンス費用なし
歴史と実績最も広く使われたCI/CDツール。情報が豊富

デメリット

デメリット説明
運用負荷サーバー管理、アップデート、セキュリティパッチが必要
UIが古い他のツールと比べてUIが洗練されていない
設定の複雑さGroovy DSLの学習コスト。プラグインの互換性問題
スケーリングマスター/エージェント構成の管理が必要
初期構築コストゼロから構築する場合の時間と労力

AWS CodePipeline

概要

AWS CodePipelineはAWSのマネージドCI/CDサービス。CodeCommit(ソース管理)、CodeBuild(ビルド)、CodeDeploy(デプロイ)と組み合わせて使う。

構成

CodePipeline(オーケストレーション)
├── Source Stage: GitHub / CodeCommit
├── Build Stage: CodeBuild
│   ├── buildspec.yml
│   ├── Docker Build
│   └── テスト実行
├── Approval Stage: 手動承認(任意)
└── Deploy Stage: CodeDeploy / ECS / CloudFormation

buildspec.yml の例

# buildspec.yml (CodeBuild)
version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 20
  pre_build:
    commands:
      - npm ci
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
  build:
    commands:
      - npm run lint
      - npm test
      - docker build -t $ECR_URI/my-app:$CODEBUILD_RESOLVED_SOURCE_VERSION .
  post_build:
    commands:
      - docker push $ECR_URI/my-app:$CODEBUILD_RESOLVED_SOURCE_VERSION

artifacts:
  files:
    - imagedefinitions.json

メリット

メリット説明
AWS統合ECS, EKS, Lambda, S3等へのデプロイが容易
IAMセキュリティきめ細かいアクセス制御
マネージドサーバー管理不要
パイプラインの可視化ステージごとの進捗を視覚的に確認

デメリット

デメリット説明
AWSロックインAWS以外の環境では利用不可
柔軟性の制約GitHub Actionsほどの柔軟なワークフロー定義ができない
エコシステムMarketplace / Orbsのような再利用パッケージが乏しい
コストパイプライン数に応じた課金($1/月/パイプライン + CodeBuild費用)
学習コストCodePipeline + CodeBuild + CodeDeploy の複数サービスの理解が必要

総合比較表

項目GitHub ActionsCircleCIJenkinsAWS CodePipeline
ホスティングクラウド(+セルフホスト)クラウド(+セルフホスト)セルフホストクラウド(AWS)
設定形式YAMLYAMLGroovy (Jenkinsfile)YAML + Console
学習コスト低〜中
運用コスト高(サーバー管理)低〜中
カスタマイズ性非常に高
エコシステムMarketplace (20K+)Orbs (3K+)Plugins (1800+)限定的
Git統合最高(GitHub)良好良好良好
デバッグやや困難SSHデバッグ可能完全に制御可能CloudWatch Logs
セキュリティGitHub Secrets / OIDCContexts自前管理IAM

料金比較

プランGitHub ActionsCircleCIJenkinsAWS CodePipeline
無料枠Public: 無制限
Private: 2,000分/月
6,000分/月
(30クレジット)
無料(OSS)1パイプライン無料
有料プランTeam: $4/user/月
+ 追加分$0.008/分
Performance: $15/月〜
(クレジット制)
サーバー費用のみ$1/パイプライン/月
+ CodeBuild費用
大規模利用Enterprise: 見積Scale: 見積サーバー費用利用量に応じて

料金は2025年時点の概算。最新の料金は各公式サイトを参照。

CI/CDパイプラインのベストプラクティス

カテゴリベストプラクティス
速度キャッシュ活用、並列実行、不要なステップ削除
信頼性テストの安定化(Flaky Test排除)、べき等なデプロイ
セキュリティシークレット管理、OIDC認証、最小権限の原則
可視化ビルドステータスバッジ、Slack通知、ダッシュボード
保守性再利用可能なワークフロー/Orbs、設定のDRY化

選定フローチャート

flowchart TD A[CI/CDツールを選ぶ] --> B{GitHubを使っている?} B -->|はい| C{シンプルなCI/CDで十分?} C -->|はい| D[GitHub Actions] C -->|高度なキャッシュ・<br/>SSHデバッグが必要| E[CircleCI] B -->|いいえ| F{オンプレミス環境?} F -->|はい| G[Jenkins] F -->|いいえ| H{AWSメインの環境?} H -->|はい| I{デプロイ先はAWSのみ?} I -->|はい| J[AWS CodePipeline] I -->|マルチクラウド| K[GitHub Actions or CircleCI] H -->|いいえ| L[GitHub Actions or CircleCI]

組み合わせパターン

実際のプロジェクトでは、複数のツールを組み合わせることもある。

パターン構成用途
GitHub Actions + CodeDeployCI: GitHub Actions
CD: AWS CodeDeploy
GitHub でCI、AWSへの安全なデプロイ
GitHub Actions + ArgoCDCI: GitHub Actions
CD: ArgoCD
GitOps。K8s環境への宣言的デプロイ
Jenkins + GitHub Actions重い処理: Jenkins (self-hosted)
軽い処理: GitHub Actions
コスト最適化

まとめ

  • GitHub Actions: GitHubユーザーにとって最も手軽で強力。第一選択肢
  • CircleCI: 高度なキャッシュ・デバッグ機能。大規模CI向け
  • Jenkins: 完全な制御が必要な場合、オンプレミス環境に最適
  • AWS CodePipeline: AWSにフルコミットしている場合のネイティブ選択肢

2025年現在、新規プロジェクトの多くはGitHub Actionsを第一選択とし、特殊な要件がある場合に他のツールを検討するのが一般的である。

参考文献