導入
CI/CDパイプラインにおいて、データベースやキャッシュサーバーへの依存をどう扱うかは大きな課題です。モック（擬似データ）でテストを済ませると、実際のクエリが正しく動作するか確認できず、本番環境で予期せぬエラーが発生することがあります。GitHub Actionsの「Service Containers」を活用すれば、ジョブ実行時にMySQLやRedisといったミドルウェアを自動で立ち上げ、本番に近い環境で信頼性の高い結合テストを容易に実行できるようになります。
基礎知識
Service Containersとは、ワークフロー実行中に一時的なコンテナをサイドカーとして起動する機能です。従来のように手動でDBをインストールしたり、外部のマネージドサービスへ接続したりする必要はありません。GitHub Actionsが自動的にネットワークブリッジを作成し、ジョブで動くメインコンテナとサービスコンテナ間での名前解決を自動化してくれます。これにより、設定ファイルに「localhost」と記述するだけで、各サービスへ接続可能になります。
実装/解決策
設定はワークフローのYAMLファイル内に `services` キーを追加するだけです。指定したイメージが自動的にプルされ、ヘルスチェックを待機した後にテストジョブが実行されます。ポイントは、ポートのマッピングと環境変数の設定です。例えばMySQLの場合、初期パスワードやデータベース名を設定することで、テストコードから即座に利用可能な状態になります。
サンプルプログラム
以下は、MySQLをサービスとして立ち上げ、テストコードから接続して検証を行うGitHub Actionsのワークフロー例です。
—
name: Database Test
on: [push]
jobs:
test:
runs-on: ubuntu-latest
# ここでサービスコンテナを定義します
services:
mysql:
image: mysql:8.0
env:
# MySQLの初期設定
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: test_db
# 起動確認用のヘルスチェック
options: >-
–health-cmd=”mysqladmin ping”
–health-interval=10s
–health-timeout=5s
–health-retries=3
ports:
- 3306:3306
steps:
- uses: actions/checkout@v3
- name: Run Test
env:
# アプリケーションから接続するための情報
DB_HOST: 127.0.0.1
DB_PORT: 3306
DB_USER: root
DB_PASS: password
run: |
# ここに実際のテストコマンドを記述します（例: npm test や pytest など）
echo “MySQLが起動しました。テストを開始します…”
# 実際にはここに接続確認やマイグレーション実行のコマンドが入ります
—
応用・注意点
現場で運用する際に特に注意すべき点は「ヘルスチェック」です。コンテナの起動コマンドと、実際に接続を受け入れ可能な状態になるまでの間にはタイムラグがあります。`–health-cmd` を省略すると、テスト開始直後にDB接続エラーが発生する可能性があるため、必ず設定するようにしましょう。また、大量のテストを行う場合は、ディスクI/Oがボトルネックになることがあります。その際は、`tmpfs` を使用してインメモリでDBを動かす設定を追加すると、テスト実行速度を劇的に向上させることが可能です。常に「本物」を使うことで、デプロイ時の不安を一つずつ解消していきましょう。
コメント