GitHub ActionsによるCI/CDの基本入門｜仕組みと全体像をわかりやすく解説

はじめに

チーム開発を行うときによく出てくるのがGitです。
Git戦略のようなものがプロジェクトごとに用意されていれば、それに従いどこからブランチを切り、まずはDevブランチにマージし、次に、、、
このように手動で、開発の履歴を残して共有することは可能です。

身近ではあったものの、私が使用してこなかったGitHubの機能の一つである、GitHub ActionsによってDeploy環境が構築されている現場で調べたことと、感じたことについてまとめました。

ブランチを作成する
Pull Request（PR）でレビューする
マージして履歴を残す

ここまでは、CI/CDツールを使わなくても問題なく行えます。
しかし、以下のことを行う場合はどうでしょう？

PR作成時に自動でテストを実行する
コードのLintやビルドエラーを検知する
マージ後に開発環境へ自動デプロイする
本番環境へ安全にリリースする（manual deploy）

もし、GitHub Actionsを使用しない場合、上記を実現するには以下のようになります。

開発者がlocalでテストを実行し、レビュワーがそれを信じる
開発者がlocalでLinterを実行し、ビルドの確認を行い、レビュワーがそれを信じる
誰かがSSHでサーバーに入り、変更を反映させる
手順書に沿ってサーバーに入り、コマンドを実行。Slackなどで結果確認

といった運用になります。
CI/CDツールがない場合、人力で行う必要があるため、再現性がなくプロジェクトが混乱してしまいます。

つまり、Gitだけでは「コード管理」はできても、「開発プロセスの自動化」まではできないのです。
そこで登場するのが GitHub ActionsによるCI/CDの構築です。
GitHub Actionsは、コードの変更をきっかけに、テスト・ビルド・デプロイを自動化できる仕組みです。
※その他のCI/CDツール：GitLab CI/CD、Bitbucket Pipelines など

本記事では、実プロジェクトで初めて経験した

GitHub ActionsによるCI/CDの基本

を整理しながら、「何を自動化し、何を人の判断に残すべきか」という観点まで解説していきます。

GitHub ActionsによるCI/CDの基本

本章では、CI/CDの基本を整理しつつ、GitHub Actionsの仕組みを理解するために必要な用語（workflow/job/stepなど）を解説します。

CI/CDとは何か？

CI/CDとは、ソフトウェア開発における作業を自動化し、品質を保ちながら素早くリリースするための考え方・仕組みです。

CI/CDは以下の2つの要素から構成されます。

CI（Continuous Integration：継続的インテグレーション）

CIとは、コードの変更が行われたタイミングで自動的にチェックを行い、品質を保つための仕組みです。
例えば、Pull Requestが作成されたときに

テストを実行する
コーディング規約（Lint）をチェックする
ビルドが成功するか確認する

といった処理を自動で実行します。
CIを導入することで、開発者が手動でテストを忘れてしまうことを防ぎ、マージ前に問題を発見しやすくなります。

CD（Continuous Delivery / Continuous Deployment）

CDは「継続的デリバリー」または「継続的デプロイ」を意味します。
CDには似た概念として、次の2つがあります。

Continuous Delivery（継続的デリバリー）
→ 本番環境へデプロイできる状態までは自動化し、最終的なリリースは人が判断して実行する
Continuous Deployment（継続的デプロイメント）
→ 本番環境へのデプロイまで自動で行い、リリースを完全に自動化する

多くのプロジェクトでは、開発環境や検証環境へのデプロイは自動化しつつ、本番環境は安全性を重視して手動（manual deploy）にするケースが多いです。

CI/CDが必要な理由

CI/CDがない場合、テストやデプロイが人の作業に依存するため、次のような問題が起きやすくなります。

テストの実行漏れが発生する
人によって作業手順が異なり品質が安定しない
手動デプロイによるミスが起きやすい
リリース作業が属人化する

CI/CDを導入することで、開発プロセスを標準化し、安定した品質で素早くリリースできるようになります。
実務ではPRをマージするときにはビルドが成功していることを確認する必要があります。正しく設定していない場合は、ビルドに失敗していてもマージできてしまう場合があるので注意が必要です。

GitHub Actionsとは？

GitHub Actionsとは、GitHubが提供するCI/CDのための自動化機能です。
GitHub Actionsを利用すると、GitHub上の操作（イベント）をきっかけにして、さまざまな処理を自動実行できます。

例えば、以下のようなタイミングで処理を実行できます。

Pull Requestが作成されたとき
mainブランチにpushされたとき
PRにラベルが付与されたとき
手動実行したとき（workflow_dispatch）

そして、そのタイミングに合わせて

テスト実行
Lintチェック
ビルド
Dockerイメージ作成
開発環境や本番環境へのデプロイ

といった作業を自動化できます。

GitHub Actionsのメリットは、コード管理を行うGitHubと同じ場所でCI/CDを構築できる点です。そのため、別途ツールを用意しなくても、リポジトリ単位で開発フローを統一しやすくなります。

GitHub ActionsでCI/CDを実現する基本構造

GitHub Actionsでは「ワークフロー（workflow）」という単位で自動化の処理を定義します。
ワークフローはリポジトリ内にYAMLファイルとして作成し、以下のディレクトリに配置します。

.github/workflows/

ワークフローの構成要素

Event（イベント）：ワークフローが実行されるきっかけ
例：push、pull_request、workflow_dispatch など
Job（ジョブ）：実行する処理のまとまり
例：テストジョブ、ビルドジョブ、デプロイジョブなど
Step（ステップ）：ジョブの中で実行する個別の処理
例：checkout、依存関係インストール、テスト実行など
Runner（ランナー）：処理を実行する環境
例：ubuntu-latest など

最小構成の例

以下は、Pull Request作成時にテストを実行するシンプルな例です。

name: CI

on:
  pull_request:

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

この設定では、Pull Requestが作成されたタイミングでジョブが実行され、テストが自動的に行われます。

GitHub Actionsが「CI/CDの自動化」になる理由

このようにGitHub Actionsでは、YAMLファイルで処理を定義することで、

PRが作成されたら自動でテストを実行する（品質確認）
mainにマージされたら検証環境へ自動デプロイする（動作確認）
本番環境へのリリースは、最終確認後に手動で実行する（安全確保）

といった開発フローをコードとして管理できます。
つまりGitHub Actionsは、単なる自動実行ツールではなく、

「開発プロセスをコード化し、再現性のある形で運用する仕組み」

と言えます。

まとめ

本記事では、GitHub ActionsによるCI/CDの基本について整理しました。

CI/CDとは何か
GitHub Actionsとはどのような仕組みか
GitHub ActionsによるCI/CDの基本構造

GitHub Actionsは単なる自動実行ツールではなく、開発プロセスそのものをコードとして管理する仕組みであることが分かります。またコードで管理するということは、コードを読めば誰でも該当リポジトリがどのようなCI/CDフローなのか一目瞭然という点が非常に魅力に感じています。
重要なのは、「とにかく自動化する」ことではなく、