MENU
  1. ホーム
  2. IT・プログラミング
  3. 【入門】CI/CDとは？Java開発で始める自動ビルドとテスト自動化

【入門】CI/CDとは？Java開発で始める自動ビルドとテスト自動化

IT・プログラミング
Java プログラム

Javaでアプリケーション開発をしていると、次のような経験はないでしょうか。

  • ローカルでは動いたのに、他の人の環境では動かない
  • 修正したら別の機能が壊れた
  • リリース直前にテスト漏れが発覚した

こうした問題の多くは、「ビルドやテストが人の手に依存している」ことが原因です。

JUnitで単体テストを書いていても、それを毎回手動で実行しているだけでは不十分な場合があります。
Maven / Gradleでビルドできても、実行を忘れれば意味がありません。

そこで登場するのが CI/CD です。

目次

CI/CDとは？

ここでは、CI/CDの基本概念と用語の意味を説明します。

CI（継続的インテグレーション）とは？

CIは Continuous Integration（継続的インテグレーション） の略です。

簡単に言うと、コードを変更するたびに、自動でビルドとテストを実行する仕組みです。

例えば、次の流れを想像してください。

  • 開発者がコードを修正する
  • Gitにpushする
  • 自動でビルドが実行される
  • 自動でテストが実行される
  • 問題があれば即座に検知される

これがCIです。

ポイントは「人が実行しなくても自動で回る」という点です。

JUnitで書いたテストも、Maven / Gradleで定義したビルドも、
CIと組み合わせることで初めて「常に実行される状態」になります。

CD（継続的デリバリー / デプロイ）とは？

CDは2つの意味で使われます。

  • Continuous Delivery（継続的デリバリー）
  • Continuous Deployment（継続的デプロイ）

両者の違いは次の通りです。

Continuous Delivery

本番環境に出せる状態まで自動化する（最終承認は人）

Continuous Deployment

本番環境への反映まで完全自動化する

つまり、CIが「品質チェックの自動化」だとすれば、CDは「リリース工程の自動化」です。

CI/CDがない開発で起きる問題

CI/CDがない場合、開発は以下のようになりがちです。

  • テストを実行し忘れる
  • 古いコードをマージしてしまう
  • 本番直前に不具合が見つかる
  • 「誰の変更が原因かわからない」状態になる

特にチーム開発では、変更が頻繁に発生します。

CIがあれば、コードが統合されるたびに自動で検証が走るため、問題を早い段階で発見できます。

これは単なる便利機能ではなく、開発の安全装置 です。

CI/CDは難しそうに見えますが、本質は次の3つです。

  • ビルドを自動化する
  • テストを自動化する
  • リリースを安全にする

CIの仕組み

ここでは、CIがどのように動いているのかを説明します。

コードをpushしたら何が起きるのか

CIは、基本的に Gitと連携 して動きます。

典型的な流れは次の通りです。

  1. 開発者がコードを修正する
  2. GitHubなどのリポジトリにpushする
  3. CIツールがpushを検知する
  4. サーバー上でビルドを実行する
  5. テストを自動実行する
  6. 結果を通知する

重要なのは、ローカル環境ではなく、別のクリーンな環境で実行されるという点です。

これにより、以下のような問題を排除することができます。

  • 自分のPCだけで動くコード
  • ローカルにしか存在しない依存関係
  • 偶然通ってしまったテスト

実務では「テストが通らないとマージできない」という運用にしているチームも多くあります。

ビルドとテストの自動実行

CIの中心は、ビルド / テストの自動実行です。

例えばMavenを使っている場合、CIサーバーは次のようなコマンドを実行します。

mvn clean package

このコマンドの中では、コンパイル、テスト実行、jarファイル生成が順番に実行されます。

Gradleであれば、gradle buildが同様の役割を果たします。

Maven / Gradleとの関係

CIは単体ではビルドやテストを実行できません。

実際にビルドやテストを実行するのは、MavenやGradleです。

役割分担は次の通りです。

  • Maven / Gradle
    → ビルドやテストを実行するツール
  • CIツール（例：GitHub Actions）
    → それを自動で実行する仕組み

つまり、CIは「指揮者」、Maven / Gradleは「演奏者」のような関係です。

あなたがすでにMaven / Gradleを使えているなら、CIの導入はそこまで難しくありません。

JavaでCIを実装してみる（GitHub Actions × Maven）

ここでは、Java × MavenプロジェクトにCIを導入する方法を説明します。

GitHub Actionsとは

GitHub Actionsは、GitHubに標準で組み込まれているCI/CD機能です。

リポジトリに設定ファイルを追加するだけで、

  • push時にビルド
  • テストの自動実行
  • 条件付きデプロイ

などを実現できます。

公式サイトはこちらです。

GitHub Actions（公式）
https://docs.github.com/actions

GitHub Actionsの利用料金

GitHub Actionsは無料で利用できますが、制限があります。

GitHubの料金体系はプランによって異なります。

Freeプランの場合（2025年時点の公式情報）

  • パブリックリポジトリ：無制限で利用可能
  • プライベートリポジトリ：月2,000分まで無料

詳細は公式料金ページを参照してください。

GitHub Pricing
https://github.com/pricing

個人学習や小規模プロジェクトであれば、無料枠で十分利用できます。

workflowファイルの作成

GitHub Actionsは、リポジトリ内に以下のディレクトリを作成することで動作します。

.github/workflows

その中にYAMLファイル.github/workflows/ci.ymlを作成します。

このファイルに「何を自動実行するか」を記述します。

Mavenビルドを自動化する最小例

以下は、mainブランチにpushされたときに
Mavenでビルドとテストを実行する最小構成です。

name: Java CI

# 実行タイミング
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # リポジトリのコードを取得
      - name: Checkout source
        uses: actions/checkout@v4

      # Java 17 をセットアップ
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      # Mavenでビルドとテストを実行
      - name: Build with Maven
        run: mvn clean package

この設定で行われる処理

このworkflowでは、次の処理が自動で実行されます。

  1. mainブランチにpush
  2. GitHubがジョブを開始
  3. Ubuntu環境を用意
  4. Java 17をインストール
  5. mvn clean package を実行
  6. JUnitテストが自動実行される

テストが失敗すると、ビルドも失敗します。

テスト失敗時の挙動

JUnitテストが失敗した場合、

・GitHub上で赤い×が表示される
・Pull Requestに失敗表示が出る
・マージを制限できる

これにより、壊れたコードがmainブランチに入ることを防げます。

CDの考え方を理解する

ここでは、CDの基本的な考え方と、実際に何が自動化されるのかを説明します。

本番環境へ自動反映とは

CDを導入すると、ビルドで生成された成果物（jarなど）をサーバーへ自動で配置できます。

例えば、次のような流れです。

  1. mainブランチにマージされる
  2. CIが成功する
  3. jarファイルが生成される
  4. サーバーへ自動転送される
  5. アプリケーションが再起動される

これが自動で行われる状態が「自動デプロイ」です。

ただし、企業開発ではいきなり本番へ完全自動反映するとは限りません。

一般的には、以下のような段階的な運用が多く採用されています。

  • ステージング環境へ自動反映
  • 人が動作確認
  • 承認後に本番へ反映

金融系や基幹システムでは、人の承認を必須にする運用もあります。

なぜ重要なのか

CDの本質は「リリース作業の再現性を高めること」です。

手動デプロイでは、以下のような問題が発生する可能性があります。

  • 手順の抜け漏れ
  • ファイルの配置ミス
  • 環境差異による不具合

CDを導入すれば、同じ手順が毎回自動で実行されます。

その結果、リリース作業が安定し、作業時間の短縮や属人化の防止につながります。

CDは高度な技術に見えますが、本質は「手動作業の自動化」です。

まずはCIを安定させ、その延長としてCDを理解する、という順番で問題ありません。

まとめ

CI/CDは難しい技術というよりも、「ビルドとテスト、リリース作業を自動化する仕組み」です。

本記事で押さえたポイントは次の通りです。

CIは、コードがpushされるたびにビルドとテストを自動実行する仕組みです。

CDは、ビルド成果物を環境へ自動反映する仕組みです。
手作業によるミスを減らし、リリースの再現性を高めます。

GitHub Actionsを使えば、特別なサーバーを用意しなくても、JavaプロジェクトにCIを導入できます。
やっていることは「コマンドの自動実行」に過ぎません。

重要なのは、CI/CDそのものを覚えることではなく、品質を保つ仕組みを作るという発想を持つことです。

  • JUnitでテストを書く
  • Mavenでビルドする
  • そしてCIでそれを自動化する

この流れができれば、あなたの開発は一段階上のレベルに進みます。

まずは小さなプロジェクトでCIを動かしてみてください。
動いた瞬間、CI/CDは「難しいもの」から「当たり前の仕組み」に変わります。

IT・プログラミング
Java プログラム
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする

CAPTCHA


目次