GitLab CI/CDを始める

(トップページはこちら)

手動でのビルド、テスト、デプロイ作業に時間を取られていませんか。コードをマージした後に本番環境で問題が発覚し、原因究明に追われた経験はないでしょうか。

GitLab CI/CDは、こうした課題を解決する継続的インテグレーション・デリバリーの仕組みです。コードのビルド、テスト、デプロイ、監視を反復的に自動実行することで、開発サイクル全体を効率化します。

この反復プロセスの最大の利点は、バグのあるコードや失敗したバージョンをベースに新しいコードを開発してしまうリスクを大幅に削減できることです。GitLab CI/CDは開発サイクルの早い段階でバグを検出し、本番環境にデプロイされるコードが確立されたコード基準に準拠していることを保証します。

本記事では、GitLab CI/CDの4つのステップを順を追って解説します。

1. パイプラインの設定

GitLab CI/CDを使用するには、プロジェクトのルートディレクトリに .gitlab-ci.yml ファイルを配置します。このファイルは、CI/CDパイプラインで実行されるステージ、ジョブ、スクリプトを指定するYAML形式の設定ファイルです。

デフォルトではファイル名は .gitlab-ci.yml ですが、任意のファイル名を使用できます。

1.1. パイプラインの構成要素

パイプラインは、ステージとジョブという2つの要素で構成されます。

ステージ

実行順序を定義します。典型的なステージには build、test、deploy があります。ステージは順番に実行され、前のステージが成功しないと次のステージには進みません。

ジョブ

各ステージで実行されるタスクを指定します。たとえば、ジョブはコードのコンパイルやテストを実行できます。同じステージ内の複数のジョブは並列に実行されるため、テスト時間を大幅に短縮できます。

以下の図は、パイプラインの実行フローを示しています。

1.2. 設定ファイルの例

実際の .gitlab-ci.yml ファイルは次のような構造になります。

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "アプリケーションをビルドしています..."
    - npm install
    - npm run build

test-job:
  stage: test
  script:
    - echo "テストを実行しています..."
    - npm run test

deploy-job:
  stage: deploy
  script:
    - echo "本番環境にデプロイしています..."
    - ./deploy.sh
  only:
    - main

このファイル内で、変数、ジョブ間の依存関係、各ジョブの実行タイミングと方法を定義します。パイプラインは、コミットやマージなどのさまざまなイベントによってトリガーできます。また、スケジュールに基づいて実行することも可能です。

詳しくはこちら

2. ランナーの検索または作成

パイプラインを定義したら、次に必要なのはジョブを実行する環境です。ランナーは、ジョブを実行するエージェントで、物理マシンまたは仮想インスタンス上で動作します。

.gitlab-ci.yml ファイル内で、ジョブの実行時に使用するコンテナイメージを指定できます。ランナーはイメージをロードし、プロジェクトをクローンして、ローカルまたはコンテナ内でジョブを実行します。

2.1. GitLab.comの場合

GitLab.comを使用している場合、Linux、Windows、macOS用のランナーがすでに利用可能です。設定不要ですぐに使い始められます。必要に応じて、独自のランナーを登録することもできます。

2.2. セルフマネージドの場合

GitLab.comを使用していない場合は、次のいずれかを実行できます。

• ランナーを登録するか、GitLab セルフマネージドインスタンス用にすでに登録されているランナーを使用します
• ローカルマシン上にランナーを作成します

独自のランナーを用意することで、特定のハードウェア要件（GPUなど）や、セキュリティ要件に対応できます。

詳しくはこちら

3. CI/CD変数と式の使用

パイプラインを柔軟に制御するには、変数と式が不可欠です。環境ごとに異なる設定値を使い分けたり、機密情報を安全に管理したりできます。

3.1. CI/CD変数

CI/CD変数は、パイプライン内のジョブに設定情報や機密情報（パスワードやAPIキーなど）を保存して渡すために使用するキーと値のペアです。

CI/CD変数を使用することで、他の場所で定義された値をジョブからアクセス可能にし、ジョブをカスタマイズできます。変数は、.gitlab-ci.yml ファイルにハードコードしたり、プロジェクト設定で設定したり、動的に生成したりできます。プロジェクト、グループ、またはインスタンスに対して定義できます。

3.1.1. 変数の種類

• カスタム変数: UI、API、または設定ファイルで作成および管理する変数です。データベース接続文字列やAPIエンドポイントなど、環境ごとに異なる値を設定できます
• 定義済み変数: GitLabが自動的に設定し、現在のジョブ、パイプライン、環境に関する情報を提供する変数です。CI_COMMIT_SHA（コミットハッシュ）や CI_PIPELINE_ID（パイプラインID）などがあります

3.1.2. セキュリティ設定

変数には、セキュリティを強化するための設定があります。

• 保護された変数: 保護されたブランチまたはタグで実行されるジョブへのアクセスを制限します。本番環境のAPIキーなど、重要な情報を安全に管理できます
• マスクされた変数: ジョブログで変数値を非表示にして、機密情報の漏洩を防ぎます。パスワードやトークンなどを設定する際に有効です

以下の図は、変数の定義からジョブでの使用までの流れを示しています。

詳しくはこちら

3.2. CI/CD式

CI/CD式を使用すると、パイプライン設定にデータを動的に注入できます。式は $[[ ]] 構文を使用し、パイプラインの作成時に検証されます。変更をコミットする前に、パイプラインエディターで式を検証することもできます。

式は、さまざまなコンテキストに基づいて動的な設定を可能にします。

3.2.1. 入力コンテキスト

$[[ inputs.INPUT_NAME ]] の形式で、include:inputs を使用して設定ファイルに渡される型付きパラメータにアクセスします。これにより、再利用可能な設定ファイルに外部から値を渡せます。

たとえば、デプロイ先の環境名を入力として受け取り、それに応じて異なる設定を適用できます。

3.2.2. マトリックスコンテキスト

$[[ matrix.IDENTIFIER ]] の形式で、ジョブの依存関係でマトリックス値にアクセスし、マトリックスジョブ間で1対1のマッピングを作成します。

複数のバージョンや環境でテストを実行する際に、マトリックス機能を使うことで設定を簡潔に保てます。

詳しくはこちら

4. CI/CDコンポーネントの使用

プロジェクトが増えると、同じようなパイプライン設定を何度も書くことになります。CI/CDコンポーネントは、この問題を解決する再利用可能なパイプライン設定単位です。

CI/CDコンポーネントを使用して、パイプライン設定全体を構成したり、より大きなパイプラインの小さな部分を構成したりできます。include:component を使用して、パイプライン設定にコンポーネントを追加できます。

4.1. コンポーネントの利点

再利用可能なコンポーネントは、次のような利点をもたらします。

• 重複の削減: 同じ設定を複数のプロジェクトで書く必要がなくなります
• 保守性の向上: 設定の変更を一箇所で行えば、すべてのプロジェクトに反映されます
• 一貫性の確保: チーム全体で同じベストプラクティスを適用できます

コンポーネントプロジェクトを作成し、CI/CDカタログに公開することで、複数のプロジェクト間でコンポーネントを共有できます。GitLabには、一般的なタスクや統合のためのCI/CDコンポーネントテンプレートも用意されています。

以下の図は、コンポーネントの作成から複数プロジェクトでの利用までの流れを示しています。

4.2. 実用例

たとえば、Docker イメージのビルドとプッシュを行うコンポーネントを作成すれば、複数のマイクロサービスプロジェクトで同じ設定を再利用できます。セキュリティスキャンやコード品質チェックなども、コンポーネント化することで組織全体で標準化できます。

詳しくはこちら

5. DevSecOpsライフサイクルにおける位置づけ

ここまで説明してきたGitLab CI/CDは、より大きなDevSecOpsライフサイクルの一部として機能します。

このライフサイクルにおいて、CI/CDは「検証」フェーズの中核を担います。コードの品質を継続的に確保することで、後続のセキュリティチェックやリリースプロセスをスムーズに進められます。

監視フェーズで得られたフィードバックは、次の計画フェーズに活かされ、継続的な改善サイクルが回ります。

6. まとめ

GitLab CI/CDは、4つのステップで継続的インテグレーション・デリバリーを実現します。

1. .gitlab-ci.yml でパイプラインを設定します
2. ジョブを実行するランナーを準備します
3. 変数と式で動的な設定を行います
4. コンポーネントで再利用性を高めます

これらの機能を組み合わせることで、次のような効果が得られます。

• バグの早期発見: コミットごとに自動テストが実行され、問題を早期に検出できます
• コード品質の維持: 一貫した基準でコードをチェックし、品質を保ちます
• デプロイの自動化: 手動作業を削減し、リリースサイクルを高速化します
• 開発チームの生産性向上: 繰り返し作業から解放され、価値の高い開発に集中できます

GitLab CI/CDは、Free、Premium、Ultimateの全ティアで利用可能で、GitLab.com、セルフマネージド、Dedicatedの全提供形態でサポートされています。小規模なプロジェクトから大規模なエンタープライズ開発まで、幅広いニーズに対応できます。

まずは簡単なパイプラインから始めて、徐々に機能を追加していくことをお勧めします。自動化の効果を実感しながら、チームに最適なCI/CDパイプラインを構築していきましょう。