JavaプロジェクトのCI/CDをGitHub Actionsで自動化｜〜「毎回同じ作業」をやめて、安心して開発を進める仕組みを作ろう〜

Javaで開発をしていると、こんな場面が何度も出てきます。

手元では動くのに、別の人の環境では動かない
マージしたら壊れていたことに気づく
リリース作業が手作業で、毎回ドキドキする
テストを回すのが面倒で、つい省いてしまう

これ、ぜんぶ「人間が頑張っている」ことが原因です。

ここで役に立つのが CI/CD。
そして、GitHubを使っているなら GitHub Actions がとても相性がいいです。

この記事では、初心者にも分かるように、

CI/CDって何を自動化するのか
Javaで最初に作るべき“最小のCI”
Maven/Gradleどちらでも使える型
ビルドを速くするキャッシュ
成果物の残し方
Secretsと権限の安全な扱い
CIからCDへ伸ばす考え方

を、ゆっくり丁寧に解説します。

CI/CDって結局なに？

難しく言わずに、まずはイメージから。

CIとは

「壊れていないことを、自動で確認する流れ」です。

たとえば、プルリクが出たら自動で

ビルドできるか
テストが通るか

をチェックします。

人が確認していたことを、仕組みが代わりにやってくれる感じです。

CDとは

「届ける作業を、自動化する流れ」です。

たとえば、メインに取り込まれたら

成果物を作る
デプロイする
配布する

といった作業を自動で進めます。

なぜJavaこそCI/CDが効くのか

Javaは、現場で長く使われる理由があります。

ビルドと依存関係が整理しやすい
テスト文化と相性がいい
チーム開発に強い
“型”を作るのが得意

つまり、CI/CDのような「繰り返しの仕組み化」と相性がいいんです。

GitHub Actionsの超基本

GitHub Actionsは、ざっくり言うと

「このタイミングで、このコマンドを動かす」

を、リポジトリ内の設定ファイルで書ける仕組みです。

よく使うタイミング

プッシュされたとき
プルリクが作られたとき
手動で起動したいとき

初心者が失敗しにくい順番はこうです。

まずCIだけ作る → 安定したらCDへ伸ばす

まず作るべき「最小のCI」

最初から全部盛りにすると、だいたい挫折します。
最小構成はこれで十分です。

ソースを取得する
Javaを用意する
依存を取り込む
ビルドとテストを実行する

ここまで自動化できるだけで、チームの安心感が一気に上がります。

Maven版：最小のCIワークフロー例

以下は、考え方が分かるようにシンプルにした例です。
（実プロジェクトでは、利用しているActionの指定はチームで固定して運用してください）

name: java-ci-maven

on:
  push:
    branches: [ main ]
  pull_request:

permissions:
  contents: read

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@vX

      - name: Set up Java
        uses: actions/setup-java@vX
        with:
          distribution: temurin
          java-version: LTS
          cache: maven

      - name: Build and test
        run: mvn -B test

ポイントは次の通りです。

プルリクでも動くようにして、壊れたまま取り込まない
権限を最小にする（最初から守りを固める）
キャッシュを使う（後述）

Gradle版：最小のCIワークフロー例

Gradleでも考え方は同じです。

name: java-ci-gradle

on:
  push:
    branches: [ main ]
  pull_request:

permissions:
  contents: read

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@vX

      - name: Set up Java
        uses: actions/setup-java@vX
        with:
          distribution: temurin
          java-version: LTS
          cache: gradle

      - name: Build and test
        run: ./gradlew test

Gradleはプロジェクトによっては実行権限の扱いが必要なことがあります。
その場合は、実行できるようにするステップを追加します。

ビルドを速くする鍵は「キャッシュ」

CIが遅い理由の多くは、ここです。

依存ライブラリのダウンロード

毎回ネットワーク越しに依存を取りに行くと、時間がかかります。
GitHub Actionsでは、キャッシュを使うことで改善しやすいです。

上の例で cache を指定しているのは、そのためです。

キャッシュが効かないときのありがち原因

依存定義を頻繁に変えている
設定ファイルの置き方がバラバラ
キャッシュ対象が揺れる書き方になっている

コツは、まずは

依存定義を落ち着かせる → キャッシュを効かせる

の順に整えることです。

成果物を残すと、チームが強くなる

CIでビルドした結果を「成果物」として残しておくと便利です。

バグ調査のとき、同じ成果物で再現できる
テスト結果を後から見られる
リリース作業につなげやすい

例として、テストレポートを成果物としてアップロードするイメージです。

      - name: Upload test report
        uses: actions/upload-artifact@vX
        with:
          name: test-report
          path: target/surefire-reports

Gradleの場合は、プロジェクトの設定に応じてレポートの場所が変わります。
大事なのは「残す」という発想です。

実務で差がつく、CIの“伸ばし方”

最小CIが動いたら、次に伸ばす候補はこれです。

静的解析（コードの怪しい部分を見つける）
フォーマットチェック（整形ルールの統一）
テストの結果を見やすくする
変更の影響が大きい部分を重点的に守る

ここで大切なのは、追加する順番です。

壊れやすいところから守る → 便利さを増やす

CDを作る前に決めたいこと

CIが安定してきたら、次はCDです。
ただし、いきなり「自動デプロイ」にすると事故が起きます。

まず決めたいのは次です。

どの環境に届けるか（開発・検証・本番の考え方）
どのタイミングで届けるか（手動承認を挟むか）
失敗したらどう戻すか

CDは「速さ」より「安全」が大事です。

Secretsと権限は、最初からちゃんとやる

CI/CDで一番怖いのは、実はここです。

パスワードやトークンが漏れる
書き換え権限を持ったまま走ってしまう
外部のActionを信用しすぎる

基本ルール

秘密情報は Secrets に入れる
ワークフローの権限は最小にする
外部Actionは チームのルールで固定する
ログに秘密が出ないようにする

「動いたからOK」ではなく、
安全に動く形にするのが、現場で信用されるやり方です。

MavenとGradle、CIでの使い分け視点

ここまで読むと、「結局どっちがいい？」となりますよね。
CIの観点では、だいたいこう考えると現実的です。

観点	Maven	Gradle
チームでの統一	型に乗せやすい	ルールを決めれば強い
設定の見通し	宣言的で読みやすい	柔軟で拡張しやすい
CIの書き方	シンプルにしやすい	タスク設計が効く
運用の注意	設定が増えると見落とし注意	自由度が高い分、統一が必須