【入門編】Bitbucket Pipelinesにおける「サービスコンテナ」の活用法:MySQLやRedisを含む統合テスト環境を瞬時に構築する – バージョン管理・CI/CD活用バイブル

Bitbucket Pipelinesの「サービスコンテナ」で、テストの常識を覆す。外部依存ゼロの爆速統合テスト環境へ

こんにちは。日々、CI/CDのパイプラインを最適化することに情熱を燃やしているエンジニアです。

皆さんは、統合テストのために「テスト用のDBサーバを別途用意する」「テストのたびにRedisを初期化するスクリプトを回す」といった、非効率な作業に時間を浪費していませんか?

特にBitbucket Pipelinesを使っているなら、それは「サービスコンテナ」という機能で劇的に解決できます。今回は、外部のインフラを一切触らず、CI環境の中でMySQLやRedisを瞬時に立ち上げ、孤立した環境でテストを完結させる「プロの現場の作法」を伝授します。

—

1. なぜ「サービスコンテナ」なのか?

通常、CIでMySQLを使う場合、外部のテスト用サーバに接続しがちです。しかし、これには大きなリスクがあります。

  • ネットワーク遅延: CIのたびに外部通信が発生し、テストが遅くなる。
  • 環境汚染: 複数のビルドが同じDBを参照し、テストデータが衝突する。
  • メンテナンス負荷: テスト用DBが壊れたら、CI全体が止まる。

サービスコンテナを使えば、「ビルドのたびに新しいMySQLが立ち上がり、ビルドが終われば跡形もなく消える」という、究極にクリーンな環境が手に入ります。

—

2. 魔法のレシピ:`bitbucket-pipelines.yml` の構成

まずは、最も頻出する「Webアプリ + MySQL + Redis」の構成例を見てください。これが現場でそのまま使えるテンプレートです。

image: php:8.2 # 言語環境を指定

pipelines:
default:

  • step:

name: 統合テストの実行
# サービスを定義。ここに書くだけで自動的に立ち上がる
services:

  • mysql
  • redis

script:
# 1. 接続確認(ここが重要!)

  • echo “Waiting for MySQL…”
  • ./wait-for-it.sh mysql:3306 –timeout=30

# 2. テスト用DBのセットアップ

  • mysql -h mysql -u root -ppassword -e “CREATE DATABASE test_db;”

# 3. テスト実行

  • vendor/bin/phpunit –configuration phpunit.xml

definitions:
services:
mysql:
image: mysql:8.0
environment:
MYSQL_DATABASE: test_db
MYSQL_ROOT_PASSWORD: password
redis:
image: redis:7.0

ここが技術の肝!

  • `definitions` セクション: サービスを部品として登録しておきます。これでコードの再利用性が高まります。
  • `wait-for-it.sh` の活用: コンテナが立ち上がっても、プロセスが完全に受け入れ可能になるまでには数秒のラグがあります。スクリプトで待機処理を入れるのが、テストを安定させる「玄人の一手」です。

—

3. 初めてのセットアップ:3つのステップ

この環境を構築するために、難しいインストール作業は不要です。

1. リポジトリの直下に `bitbucket-pipelines.yml` を作成する

  • Bitbucketのリポジトリ設定画面から「Pipelines」を有効にするだけです。

2. 必要なツールをコンテナに入れる

  • `script` 内で `apt-get install -y mysql-client` のように、必要なクライアントライブラリをインストールします。これだけで、コンテナ内のMySQLをローカル操作できるようになります。

3. 環境変数を書き換える

  • あなたのアプリケーションのDB接続設定を、`localhost` ではなく、サービス名である `mysql` を向くように変更してください。これでパイプライン内での通信が確立します。

—

4. 精度を高めるためのアドバイス

初心者が陥りやすい罠として、「テストが終わってもDBの中身が汚れたままになる」という問題があります。しかし、サービスコンテナなら心配無用。ビルドが終了した瞬間にコンテナは破棄されるため、毎回必ず「新品のDB」からテストが始まります。

もしテストが遅いと感じたら、以下の2点をチェックしてください。

  • イメージの軽量化: `mysql:latest` ではなく、`mysql:8.0-alpine` のような軽量なイメージを使う。
  • キャッシュの活用: `caches` セクションを併用して、依存関係(ComposerやNPMのパッケージ)をキャッシュする。

—

最後に:自動化がもたらす「心の余裕」

これまで手動で確認していたテスト、あるいは外部サーバの不調に泣かされていた時間は、すべて「無駄」です。

サービスコンテナを使いこなすことで、あなたのチームのCIは「何度実行しても結果が変わらない(冪等性の高い)」強固なものになります。環境のことはツールに任せて、あなた自身は「より良いコードを書くこと」に集中してください。

何か不明点があれば、いつでも聞いてくださいね。あなたの開発が今日から少しでも楽になることを願っています。応援していますよ!

タイトルとURLをコピーしました