🛠️

CI/CD入門第3回：GitHub Actionsを利用したCIワークフローの構築～パイプラインの全体像～

に公開
Docker
GitHub Actions
CI
DevOps
tech

はじめに

皆さん、こんにちは。オアシステクノロジーズの古本です。DevOps基礎シリーズの第3回へようこそ。

これまでの話を振り返ってみましょう。

  • 第1回: なぜDevOpsが重要で、その中核をなすCI/CDがどのような概念なのかを学びました。
  • 第2回: CI/CDパイプラインを流れる「信頼できる成果物」として、Dockerイメージがいかに強力であるかを理解しました。

そして今回は、いよいよ実践編です。
第2回で学んだDockerイメージを、GitHub Actions を使って自動的にビルドし、コンテナレジストリに登録するまでの CI（継続的インテグレーション）ワークフロー を構築します。

この20分で、皆さんがCIパイプラインの全体像を掴み、簡単なワークフローなら自力で構築できる状態になることを目指します。

1. GitHub Actionsとは？

GitHub Actionsは、GitHubに標準で組み込まれているCI/CDプラットフォームです。
皆さんが普段使っているGitHubリポジトリで、git push や Pull Request の作成といったイベントをきっかけに、テスト、ビルド、デプロイなどのあらゆる処理を自動化できます。

なぜ今、GitHub Actionsなのか？

CI/CDツールはJenkinsやCircleCIなど他にも多く存在しますが、GitHub Actionsには以下のような強みがあります。

  • GitHubとの圧倒的な親和性: リポジトリと一体化しているため、設定が非常にシンプル。
  • 豊富な「Actions」: マーケットプレイスに公開されている無数の「Action」（再利用可能な処理の部品）を組み合わせるだけで、高度なワークフローを簡単に構築できます。
  • 寛大な無料利用枠: パブリックリポジトリなら完全無料。プライベートリポジトリでも十分な無料時間が提供されており、スモールスタートに最適です。

0→1開発において、インフラの専門家がいなくても手軽に始められるGitHub Actionsは、まさにうってつけのツールと言えるでしょう。

2. GitHub Actionsの主要な概念

ワークフローを構築する前に、いくつか重要なキーワードを覚えましょう。これさえ押さえれば、YAMLファイルが読めるようになります。

GitHub Actions Concepts
公式ドキュメントより引用

  • Workflow (ワークフロー)
    • 自動化したいプロセス全体のこと。1つのリポジトリに複数のワークフローを作成できます。
    • .github/workflows/ ディレクトリに配置された YAMLファイル で定義します。
  • Event (イベント)
    • ワークフローを起動する「きっかけ」となる操作です。
    • 例: mainブランチへのpush、pull_requestの作成など。
  • Job (ジョブ)
    • ワークフローを構成するタスクの集まり。buildやtestといった単位で作成します。
    • 各ジョブは、後述する「ランナー」上で実行されます。デフォルトでは複数のジョブは並列で実行されます。
  • Step (ステップ)
    • ジョブの中で実行される個々の処理です。
    • シェルコマンドを実行したり、後述の「Action」を呼び出したりします。ステップは上から順に実行されます。
  • Action (アクション)
    • ワークフローで利用できる「再利用可能な部品」です。
    • actions/checkout@v3 のように、コミュニティが作成した便利なActionを簡単に利用できます。
  • Runner (ランナー)
    • ワークフローを実行するための仮想サーバー環境です。
    • GitHubが提供する GitHub-hosted runner (ubuntu-latestなど) を使うのが一般的です。

これらの関係は、「イベントをきっかけにワークフローが起動し、ランナー上でジョブが実行される。ジョブは一連のステップで構成され、各ステップではコマンドやアクションが実行される」と整理できます。

3. CIパイプラインの全体像をYAMLで見てみよう

それでは、第2回で触れたCIのプロセスをGitHub Actionsで実現するワークフローを見ていきましょう。
ここでのゴールは、「mainブランチにコードがpushされたら、自動でDockerイメージをビルドし、Docker Hubにpushする」です。

リポジトリの .github/workflows/ci.yml というファイルに、以下のように記述します。

.github/workflows/ci.yml
# ワークフローの名前
name: CI Workflow

# ワークフローが実行されるきっかけ (Event)
on:
  push:
    branches: [ "main" ] # mainブランチへのpush時のみ

# 実行される一連のタスク (Job)
jobs:
  # ジョブのID (任意の名前)
  build-and-push-image:
    # ジョブを実行する環境 (Runner)
    runs-on: ubuntu-latest

    # ジョブを構成する一連の処理 (Step)
    steps:
      # Step 1: リポジトリのコードをチェックアウトする
      - name: Checkout repository
        uses: actions/checkout@v3

      # Step 2: Docker Hubへログインする
      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      # Step 3: Dockerイメージをビルドしてプッシュする
      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: your-dockerhub-username/my-node-app:latest

各ステップの解説

  • on: mainブランチにpushがあった時だけ、このワークフローが動くように設定しています。
  • jobs: build-and-push-imageという名前のジョブを1つだけ定義しています。
  • runs-on: ubuntu-latest: このジョブが、GitHubが用意した最新のUbuntu環境で実行されることを指定します。
  • steps: ここからが具体的な処理です。
    1. actions/checkout@v3: まず最初に、ワークフローを実行するランナー上にリポジトリのソースコードを持ってくる必要があります。これは定型句として覚えておきましょう。
    2. docker/login-action@v2: Docker Hubにイメージをpushするために、ログイン処理を行います。usernameとpasswordは、直接YAMLに書くのではなく、GitHubの Secrets 機能に登録しておくのがベストプラクティスです。これにより、パスワードなどの機密情報を安全に扱うことができます。
    3. docker/build-push-action@v4: このActionがCIの心臓部です。
      • context: .: Dockerfileがある場所（この場合はリポジトリのルート）を指定します。
      • push: true: ビルド後にDocker Hubへpushすることを指定します。
      • tags: リポジトリ名/イメージ名:タグ の形式で、pushするイメージの名前を指定します。

たったこれだけのYAMLファイルで、第2回で学んだ「CIフェーズのゴール（テスト済みの、いつでもデプロイ可能なDockerイメージをコンテナレジストリに保管すること）」への第一歩が実現できました。

4. ワークフローの実行を確認する

この ci.yml ファイルをリポジトリの .github/workflows/ ディレクトリに配置してmainブランチにpushすると、ワークフローが自動的に実行されます。

実行状況は、リポジトリの 「Actions」 タブからリアルタイムで確認できます。

Actions Tab

Job Detail
https://dev.classmethod.jp/articles/dependabot-updates-now-visible-in-github-actions-workflow-list/

各ステップの実行ログや、成功/失敗の結果もここで全て見ることができるので、問題が発生した際のデバッグも容易です。

まとめと次回予告

今回のポイント

  • GitHub Actions は、GitHubリポジトリと統合された強力なCI/CDツールである。
  • ワークフロー はYAMLで定義し、イベント, ジョブ, ステップ などの要素で構成される。
  • actions/checkoutやdocker/build-push-actionといった便利なアクションを組み合わせることで、Dockerイメージのビルドとプッシュを簡単に自動化できる。

CIパイプラインの全体像、掴めてきたでしょうか？
開発者はただコードをgit pushするだけ。あとはGitHub Actionsが、Dockerイメージという標準化された成果物を自動でビルdして管理してくれる。これが現代的な開発の第一歩です。

さて、今回のワークフローは非常にシンプルでした。しかし、実際の開発では「テストやLintを別々のジョブとして実行したい」「Pull Requestのたびにテストを動かしたい」といった、より複雑な要求が出てきます。

次回、第4回では、今回作成したCIワークフローをより実践的にするために、複数のジョブを連携させる方法や、ブランチ戦略と組み合わせたワークフローの管理について詳しく解説します。

お楽しみに！

Discussion