GitLab CI/CDパイプライン入門｜自動テスト環境の構築

GitLab CI/CDパイプラインを活用すれば、コードのビルド・テスト・デプロイを自動化し、開発効率を最大300%向上させられます。本記事では、初心者でも実践できるGitLab CI/CDの設定方法を、具体的な手順とサンプルコードで解説します。自動テスト環境の構築から本番デプロイまで、一貫したCI/CDワークフローを構築する方法を学びましょう。

GitLab CI/CDとは

GitLab CI/CD（Continuous Integration/Continuous Delivery）は、GitLabが提供する自動化フレームワークです。開発からテスト、デプロイまでの一連のプロセスを自動化し、ソフトウェア品質の向上とリリースサイクルの短縮を実現します。

GitLab CI/CDの主な特徴は以下の通りです：

  • 統合環境：GitLabのリポジトリとCI/CDがシームレスに連携
  • 柔軟な設定：YAML形式でパイプラインを定義可能
  • スケーラビリティ：並列実行や依存関係の管理が容易
  • セキュリティ：シークレット管理やアクセス制御機能

GitLab公式の調査によると、CI/CDを導入したチームは平均でリリース頻度が4倍向上し、バグ発見率が30%低下すると報告されています（出典: GitLab DevSecOps Survey 2023）。

CI/CDと従来の開発フロ…

従来の開発フローCI/CDを活用した開発フロー
手動でテストを実行コードプッシュ時に自動テスト実行
リリース前に手動でビルドコード変更時に自動ビルド
リリースサイクルが長い小さな変更を頻繁にリリース
バグ発見が遅れる早期にバグを検出

CI/CD環境のセットアップ

GitLab CI/CDを開始するには、以下の準備が必要です：

1. GitLabアカウン…

GitLabの公式サイト（https://gitlab.com）から無料アカウントを作成します。個人利用であれば無料プランで十分ですが、プライベートリポジトリを使用する場合は有料プランが必要です。

2. プロジェクトの作成

GitLabにログイン後、以下の手順で新規プロジェクトを作成します：

  1. 右上の「New project」ボタンをクリック
  2. 「Create blank project」を選択
  3. プロジェクト名と可視性（Public/Private）を設定
  4. 「Create project」をクリック

3. Runnerのインス…

GitLab Runnerは、CI/CDジョブを実行するためのエージェントです。以下の手順でインストールします：

Linux（Ubuntu/Debian）へのインストール

# GitLab Runnerの公式リポジトリを追加
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash


GitLab Runnerをインストール

sudo apt-get install gitlab-runner


Runnerを登録

sudo gitlab-runner register

登録時に以下の情報を入力します：

  • GitLab instance URL: https://gitlab.com
  • Registration token: プロジェクトのSettings > CI/CD > Runners
  • Description: 任意のRunner名
  • Tags: 任意のタグ（例: docker, linux）
  • Executor: docker（推奨）またはshell

Docker Executorの設定

Docker Executorを使用すると、各ジョブが独立したコンテナで実行されるため、環境の整合性が保たれます。以下の手順で設定します：

# Dockerをインストール
sudo apt-get update
sudo apt-get install -y docker.io


GitLab Runnerユーザーをdockerグループに追加

sudo usermod -aG docker gitlab-runner


GitLab Runnerを再起動

sudo systemctl restart gitlab-runner

4. 必要なツールのインス…

CI/CDパイプラインで使用するツールをRunnerにインストールします。一般的なツールは以下の通りです：

  • Git
  • Node.js（JavaScriptプロジェクトの場合）
  • Python（Pythonプロジェクトの場合）
  • Docker
  • 各種テストツール（Jest, pytest, RSpecなど）

これらのツールは、.gitlab-ci.yml内で各ジョブのbefore_scriptセクションでインストールできます。

基本的なCI/CDパイプラインの作成

GitLab CI/CDパイプラインの核となるのが.gitlab-ci.ymlファイルです。このYAMLファイルでパイプラインの構成を定義します。

.gitlab-ci.ymlの設定方法

プロジェクトのルートディレクトリに.gitlab-ci.ymlファイルを作成します。以下は基本的な設定例です：

stages:
  - test
  - build
  - deploy

test-job:
  stage: test
  script:
    - echo "Running tests..."
    - npm test  # Node.jsプロジェクトの場合

build-job:
  stage: build
  script:
    - echo "Building application..."
    - npm run build

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - ./deploy.sh
  only:
    - main

主要なセクションの説明

セクション説明例
stagesパイプラインのステージを定義- test
- build
- deploy
job名ジョブの識別子test-job:
stageジョブが属するステージstage: test
script実行するコマンドscript:
- echo "Hello"
only/except実行条件を指定only:
- main

ステージとジョブの定義

ステージはパイプラインの段階を表し、ジョブは各ステージで実行されるタスクです。ステージは以下の順序で実行されます：

  1. testステージ
  2. buildステージ
  3. deployステージ

各ステージ内のジョブは並列実行されます。ステージ間の依存関係は自動的に管理されます。

依存関係のあるジョブの定義

特定のジョブが他のジョブの成果物に依存する場合はneedsキーワードを使用します：

build-job:
  stage: build
  script:
    - echo "Building application..."
  artifacts:
    paths:
      - dist/

deploy-job:
  stage: deploy
  script:
    - echo "Deploying..."
  needs:
    - job: build-job
      artifacts: true

アーティファクトとキャッシュの活用

アーティファクトとキャッシュは、CI/CDパイプラインの効率を向上させる重要な機能です。

アーティファクト

アーティファクトは、ジョブの実行後に保存されるファイルやディレクトリです。他のジョブで使用できます。

test-job:
  stage: test
  script:
    - npm test
  artifacts:
    paths:
      - coverage/
    reports:
      junit: test-results.xml

一般的なアーティファクトの用途：

  • テストカバレッジレポート
  • ビルド成果物（dist/、build/）
  • ドキュメント（docs/）
  • テスト結果（JUnit形式）

キャッシュ

キャッシュは、ジョブ間で再利用できるファイルを保存します。主に依存関係のダウンロードを高速化します。

test-job:
  stage: test
  script:
    - npm install
    - npm test
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

キャッシュのベストプラクティス：

  • キャッシュキーには${CI_COMMIT_REF_SLUG}（ブランチ名）を使用
  • 依存関係（node_modules/、vendor/）をキャッシュ
  • 頻繁に変更されるファイルはキャッシュしない

応用テクニック

基本的なCI/CDパイプラインを構築したら、より高度なテクニックを活用してパイプラインを最適化しましょう。

Dockerとの連携

Dockerを活用すると、一貫した実行環境を提供し、依存関係の問題を解決できます。GitLab CI/CDでは、Dockerイメージを使用してジョブを実行できます。

カスタムDockerイメージの使用

独自のDockerイメージを使用するには、imageキーワードを指定します：

test-job:
  stage: test
  image: node:18
  script:
    - npm install
    - npm test

Docker-in-Docker（DinD）の設定

ジョブ内でDockerコンテナを実行する場合は、Docker-in-Docker（DinD）を有効にします：

services:
  - docker:dind

test-job:
  stage: test
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker build -t my-app .
    - docker run my-app npm test

Dockerイメージのビルドとプッシュ

アプリケーションのDockerイメージをビルドして、レジストリにプッシュする例です：

build-docker-image:
  stage: build
  image: docker:20.10
  services:
    - docker:dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:latest
  only:
    - main

並列ジョブの実行

GitLab CI/CDでは、ジョブを並列実行することでパイプラインの実行時間を短縮できます。並列実行にはparallelマトリックスを使用します。

並列テストの実行

テストを並列実行する例です：

test:
  stage: test
  parallel:
    matrix:
      - TEST_GROUP: [1, 2, 3, 4]
  script:
    - npm test -- --group $TEST_GROUP

この設定では、4つの並列ジョブが実行され、各ジョブで異なるテストグループを実行します。GitLab Premiumを使用すると、最大50並列ジョブまで実行できます。

依存関係のある並列ジョブ

並列ジョブ間で依存関係がある場合はneedsを使用します：

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  parallel:
    matrix:
      - TEST_GROUP: [1, 2, 3]
  script:
    - npm test -- --group $TEST_GROUP
  needs:
    - job: build
      artifacts: true

手動承認を要するデプロイ

本番環境へのデプロイなど、重要なジョブは手動承認を必要とする場合があります。GitLab CI/CDではwhen: manualを使用して手動ジョブを定義します。

deploy-production:
  stage: deploy
  script:
    - ./deploy-to-production.sh
  when: manual
  only:
    - main

手動ジョブは、GitLab UIのパイプライン画面から手動で実行する必要があります。承認が必要な場合は、rulesを使用して承認者を指定できます：

deploy-production:
  stage: deploy
  script:
    - ./deploy-to-production.sh
  when: manual
  rules:
    - if: $CI_COMMIT_REF_NAME == "main"
      when: manual
      allow_failure: false

セキュリティベストプラクティス

CI/CDパイプラインはソフトウェアの品質とセキュリティに大きな影響を与えます。以下のベストプラクティスに従って、セキュアなパイプラインを構築しましょう。

1. シークレットの管理

APIキー、パスワード、証明書などの機密情報は、.gitlab-ci.ymlファイルに直接記述してはいけません。GitLabのCI/CD変数機能を使用します。

CI/CD変数の設定

  1. プロジェクトのSettings > CI/CD > Variablesに移動
  2. 「Add variable」をクリック
  3. 変数名と値を入力（例: DOCKER_PASSWORD）
  4. Mask変数にチェックを入れて値を非表示にする
  5. Protect変数にチェックを入れてmainブランチでのみ使用可能にする

変数を.gitlab-ci.ymlで使用するには、$変数名または${変数名}の形式で記述します：

deploy-job:
  stage: deploy
  script:
    - echo $DOCKER_PASSWORD | docker login -u $DOCKER_USER --password-stdin

2. 最小権限の原則

CI/CDジョブに与える権限は最小限に抑えます。例えば、本番環境へのデプロイには専用のデプロイキーを使用します。

専用のデプロイユーザーの作成

GitLab RunnerやCI/CDジョブに専用のユーザーを作成し、必要な権限のみを付与します。例えば、AWSの場合はIAMロールを使用します。

3. セキュリティテストの…

CI/CDパイプラインにセキュリティテストを組み込むことで、脆弱性を早期に発見できます。

SAST（Static Application Security Testing）

GitLab UltimateにはSAST機能が組み込まれており、コードの静的解析を行います。有効にするには.gitlab-ci.ymlに以下を追加します：

include:
  - template: Security/SAST.gitlab-ci.yml

sast:
  stage: test

Dependency Scanning

依存関係の脆弱性を検出するDependency ScanningもGitLab Ultimateで利用できます：

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml

dependency_scanning:
  stage: test

4. イメージの信頼性確保

使用するDockerイメージは公式のものを使用し、可能な限り最新のセキュリティパッチが適用されたものを選択します。

イメージの検証

カスタムイメージを使用する場合は、以下の手順で検証します：

  • 公式のベースイメージから作成されたイメージか確認
  • 必要なパッケージのみインストールされているか確認
  • rootユーザーで実行しないように設定
FROM node:18-alpine


rootユーザーで実行しない

USER node


必要なパッケージのみインストール

RUN npm install --production


アプリケーションを実行

CMD ["npm", "start"]

トラブルシューティング

CI/CDパイプラインの実行中に発生する一般的な問題とその解決方法を紹介します。

1. ジョブが失敗する

ジョブが失敗する主な原因と対処法：

原因対処法
コマンドの実行に失敗ジョブのログを確認し、エラーメッセージを特定
タイムアウトtimeoutキーワードでタイムアウト時間を延長
メモリ不足Runnerのリソースを増強またはジョブを軽量化
依存関係の不足before_scriptで依存関係をインストール

ジョブログの確認方法

  1. GitLab UIでパイプラインを開く
  2. 失敗したジョブをクリック
  3. 「Job log」タブで詳細なログを確認

2. アーティファクトが見…

アーティファクトが見つからない場合の原因と対処法：

  • 原因1：ジョブが失敗した
    • アーティファクトは成功したジョブでのみ保存される
    • 失敗したジョブのアーティファクトは保存されない
  • 原因2：パスが間違っている
    • artifacts.pathsで指定したパスが正しいか確認
    • ジョブの実行ディレクトリ（通常/builds/...）からの相対パスを使用
  • 原因3：ストレージ容量の制限
    • GitLabのストレージ制限に達している可能性あり
    • 管理者にストレージ容量の拡張を依頼

3. Runnerがジョブ…

Runnerがジョブを実行しない場合の原因と対処法：

  • 原因1：Runnerがオフライン
    • Runnerのステータスを確認（sudo gitlab-runner verify）
    • Runnerを再起動（sudo systemctl restart gitlab-runner）
  • 原因2：タグが一致しない
    • ジョブにタグが指定されている場合、Runnerも同じタグを持っている必要あり
    • Runnerの登録時にタグを設定
  • 原因3：ジョブの条件に一致しない
    • onlyやexceptの条件を確認
    • ブランチ名やタグ名が正しいか確認

4. キャッシュが効かない

キャッシュが効かない場合の原因と対処法：

  • 原因1：キャッシュキーが異なる
    • キャッシュキーが変更されると新しいキャッシュが作成される
    • cache.keyを固定値にするか、${CI_COMMIT_REF_SLUG}を使用
  • 原因2：キャッシュのパスが間違っている
    • cache.pathsで指定したパスが正しいか確認
    • ジョブの実行ディレクトリからの相対パスを使用
  • 原因3：キャッシュが期限切れ
    • GitLabのデフォルトではキャッシュは1週間で期限切れ
    • cache:policy:pullを使用してキャッシュを更新

よくある質問

Q1. GitLab CI…

GitLab CI/CDとGitHub Actionsの主な違いは以下の通りです：

機能GitLab CI/CDGitHub Actions
統合環境GitLabと完全に統合GitHubと統合
Runnerの管理独自のRunnerを管理可能GitHub-hosted Runnerと独自Runner
ストレージ無料プランで10GB無料プランで500MB
価格無料プランあり（制限あり）無料プランあり（制限あり）
セキュリティ機能SAST、Dependency ScanningなどCodeQL、Dependabotなど

GitLab CI/CDはGitLabとの統合が強く、特にGitLabを使用しているチームに適しています。GitHub ActionsはGitHubリポジトリとの統合が強く、GitHubを使用しているチームに適しています。

Q2. CI/CDパイプラ…

CI/CDパイプラインの実行時間を短縮するための具体的な方法を紹介します：

  • 並列実行の活用
    • 独立したジョブはparallelマトリックスで並列実行
    • GitLab Premiumを使用すると最大50並列ジョブまで実行可能
  • キャッシュの最適化
    • 依存関係（node_modules/、vendor/）をキャッシュ
    • キャッシュキーには${CI_COMMIT_REF_SLUG}を使用
    • 頻繁に変更されるファイルはキャッシュしない
  • 軽量なDockerイメージの使用
    • Alpine Linuxベースのイメージを使用
    • 必要なパッケージのみインストール
  • ステージの最適化
    • 必須のジョブのみ実行するようにrulesを設定
    • テストやビルドなど、実行時間の長いジョブを並列化
  • Runnerのリソース増強
    • CPUやメモリを増強したRunnerを使用
    • オンプレミスのRunnerを使用してネットワーク遅延を軽減

GitLabの調査によると、これらの最適化により平均でパイプラインの実行時間を60%短縮できると報告されています（出典: GitLab CI/CD Best Practices）。

Q3. CI/CDパイプラ…

CI/CDパイプラインでDockerを使用する主なメリットは以下の通りです：

  • 一貫した実行環境
    • 開発環境、テスト環境、本番環境で同じ環境を使用
    • 依存関係の問題を解決
  • 隔離された実行
    • 各ジョブが独立したコンテナで実行される
    • ジョブ間の干渉を防止
  • 高速な起動
    • Dockerコンテナは軽量で高速に起動
    • 従来の仮想マシンよりも高速
  • セキュリティの向上
    • rootユーザーで実行しないように設定可能
    • コンテナ間のネットワーク隔離
  • 再現性の向上
    • Dockerfileで環境を定義可能
    • 環境のバージョン管理が容易

GitLabの公式ドキュメントによると、Dockerを使用したCI/CDパイプラインは、従来の方法と比較して平均で40%高速に実行できるとされています（出典: GitLab Docker Integration）。

Q4. CI/CDパイプラ…

CI/CDパイプラインで使用するDockerイメージのベストプラクティスを紹介します：

  • 公式イメージを使用する
    • 可能な限り公式のDockerイメージを使用
    • 例: node:18、python:3.11、alpine:latest
  • 軽量なイメージを選択する
    • Alpine Linuxベースのイメ
      【編集・制作ポリシー】
      本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
      ABOUT ME
      たから
      サラリーマンをしながら開業して経営やってます。 今年、本業で独立・別事業を起業予定です。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900/FE/サーティファイC言語 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営