はじめに

この記事では以下のことについて説明しています。

GitHub ActionsでCI/CDを実現する方法
CI/CDを実現する上で考えておきたいこと

CI/CDについてさらっと説明しましょう。

CI/CDとは

CIとは「Continuous Integration: 継続的インテグレーション」のことで、コミットのたびにテストやビルドなどを諸々を自動で実行されるようにして、品質を保ちつつ開発スピードを上げる という開発プロセスです。

CDとは「Continuous Delivery: 継続的デリバリー」のことで、変更がメインブランチにマージされたら自動でテストとビルドを行い、プロダクトをいつでもデプロイ（リリース）できる状態まで自動で整えるプロセスのことです。実際に本番デプロイするのは自動で行わず、手動で行います。だいたいCIだけ or CDだけをやることはなく一緒にやるので「CI/CD」とまとめて呼ばれます。

また、CI/CDと合わせて語られる「継続的デプロイメント」はコードをできるだけ頻繁にデプロイして常にプロダクトを新しい状態に保つようにする 開発プロセスです。継続的デリバリーが手動でデプロイするのに対して、こちらはデプロイまで自動で行われます。

CI/CDの範囲の考え方は色々あるみたいで、継続的デリバリーと継続的デプロイメントをまとめて「CD」としたり、CIの範囲を「継続的インテグレーションと継続的デリバリー」として、CDを「継続的デプロイメント」と定義していたりします。

参考

定義はなんだってよくって、要するに品質を担保する部分（テスト）だったり本番環境への反映の準備（ビルド）などの実際の開発作業以外の部分を自動化して、開発スピードを上げていこうという考え方です。

GitHub Actions を利用した CI では、リポジトリ中のコードをビルドしてテストを実行できるワークフローが利用できます。本記事では「ワークフローで自動テストを実行する」テンプレートについて紹介していきます。

GitHub Actionsのワークフローを使う

.github/workflows ディレクトリをプロジェクトルートに作る
ワークフローファイルを構成する
トリガー条件を起こす

と言う流れです。

`.github/workflows` ディレクトリを作成

.
├── .github
│   └── workflows
├── src
│   ├── hoge
│   └── index.ts
├── test
│   └── hoge.test.ts
└── tsconfig.json

ワークフローファイルを構成する

作成した .github/workflows にワークフローを記述する test.yml を置きます。

├── .github
│   └── workflows
│         └── test.yml # ワークフローファイル
├── src
│   ├── hoge
│   └── index.ts
├── test
│   └── hoge.test.ts
└── tsconfig.json

書き方は以下を見てください。

ビルドとテストのテンプレートが以下にあるので、Node.js用のものを見てみましょう。

テストとビルドのワークフロー

name: Node.js CI

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
            node-version: '20.11.0'
      - run: npm ci
      - run: npm run build
      - run: npm test

このワークフローでは、push イベントがトリガーとなって以下のアクションが順に実行されます。

コードのチェックアウト: リポジトリの最新のコードを取得
Node.js のセットアップ: 指定されたバージョン（20.11.0）の Node.js をセットアップ
依存関係のインストール: npm ci コマンドで依存関係をインストール
ビルドの実行: npm run build コマンドでプロジェクトをビルド
テストの実行: npm test コマンドでテストを実行

変更をcommitしてpushすると、ワークフローが実行されます。GitHub の Actions のタブでその結果が確認できます。

おまけ: mainブランチへのPRが作成された時にワークフローを実行する

commitのたびにトリガーを発動させたくないよって言う方におすすめです。
トリガー条件を以下のように書き換えましょう。

on:
  pull_request:
    types: [opened, synchronize]
    branches: [ main ]

CDの部分は？

本カレンダーにおいてはTerraformをデプロイで使用しており、matser へのマージとそのワークフローの成功が確認できた時に terraform apply を行います。手動デプロイということで一旦これにてCD（継続的デリバリー）を達成しているとみなします（合っている？）。

CI/CDを実現する上で考えておきたいこと

チェック項目はバランスよく

今回は雑に必要最低限の機能を用意しましたが、型チェック, Lintなども追加で行っておきたいです。とはいえチェック項目を増やしすぎると実行時間が増えて無料枠をはみ出してしまうので注意です。

ワークフローのエラーには気づけるようにする

メールとかにはエラーメッセージは来ているかもですが、気付けなければ意味がありません。気付けるような通知もGitHub上で設定するなりWorkflowで設定するなりしましょう。

無料枠にできるだけ抑える

公開レポジトリであれば無料です。プライベートレポジトリであれば以下の料金になっています。無料プランであればおよそ33時間, 有料プランであれば50時間の実行時間の無料枠があります。

プラン	Storage	分(月あたり)
GitHub Free	500 MB	2,000
GitHub Pro	1 GB	3,000

そんなガッツリ使うこともないでしょうが、永遠に終わらないジョブを走らせっぱなしにしてしまい、ソッコーで無料枠を使い切ってしまうなんてことがないように気をつけましょう。

おわりに

今回は簡単にCI/CDを実現する方法について説明しました。次回はなんか説明します。