製品プロフィール

GitLab CI/CD

GitLab / CI/CD(GitLab 統合)

GitLab に統合された CI/CD。`.gitlab-ci.yml` でパイプラインを定義し、ソース管理から運用まで一気通貫。

3つの要点
TL;DR
  1. GitLab 内蔵の CI/CD。.gitlab-ci.yml でパイプライン定義。
  2. ソース管理〜CI/CD〜運用を一体で扱え DevOps 機能が充実。
  3. GitLab 中心やオンプレ統合に最適。全機能は有料プラン。

基本情報

仕様と立ち位置

GitLab CI/CD のロゴ
製品・技術の概要GitLab CI/CDGitLab に統合された CI/CD。`.gitlab-ci.yml` でパイプラインを定義し、ソース管理から運用まで一気通貫。
種別
CI/CDGitLab 統合)
提供元
GitLab
ライセンス
オープンソース+商用
登場
2015年
最大の強み
ソース〜CI/CD〜運用が一体セルフホスト/SaaS の両対応
代表的な用途
GitLab 中心の DevOpsオンプレ統合環境

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. ソース〜CI/CD〜運用が一体
  2. セルフホスト/SaaS の両対応
  3. DevOps 機能が充実

事前に確認する条件

考慮すべき点

  1. GitLab 前提
  2. 全機能は有料プラン

詳しい解説

もっと詳しく

どんなツールか

GitLab CI は、GitLab に統合された CI/CD の仕組みです。GitLab 上のリポジトリに対して、ビルド・テスト・デプロイといった処理を自動で実行できます。

「結局なに?」を一言でいえば、GitLab に最初から組み込まれた自動化機能です。ソース管理から CI/CD、課題管理、コンテナレジストリまで一つのプラットフォームでまとめて扱える点が特徴です。

横にスクロール

GitLab の変更からパイプライン作成規則、DAG ジョブ、Runner、成果物、環境へのデプロイへ進む実行経路
GitLab CI は rules で作成対象を絞り、needs で必要なジョブだけを待つと、無駄なパイプラインと待ち時間を減らせます。成果物とキャッシュ、保護変数と保護環境は役割を分けて扱います。

特徴・仕組み

パイプラインはリポジトリ直下の .gitlab-ci.yml で定義します。処理はステージ(例: build → test → deploy)に分かれ、同一ステージのジョブは並列、ステージ間は順に進みます。

test:
  stage: test
  script:
    - npm install
    - npm test
  • Runner: 実際にジョブを実行する環境。GitLab 提供の共有 Runner か、自前登録の Runner を選べる。Docker・Kubernetes 等で実行できる。
  • needs による DAG: ステージ順に縛られず、依存関係だけで先行実行させ高速化できる。
  • 統合機能: 環境(Environments)、レビュー用の一時環境、コンテナレジストリ、セキュリティスキャンなどが同じ画面に揃う。

得意・不得意

  • ソース管理から CI/CD・レジストリ・課題管理まで一体で、ツールをまたがず DevOps を完結できる。
  • リポジトリに .gitlab-ci.yml を置くだけで始められ、設定が分散しにくい。
  • 反面、GitLab を使っていることが前提。他基盤が中心の環境には馴染みにくい。共有 Runner の実行時間には上限がある(自前 Runner で回避可)。

他の CI との違い

観点GitLab CIGitHub Actions
前提基盤GitLabGitHub
統合範囲SCM・CI・レジストリ・課題を一体GitHub と密+アクション
定義ファイル.gitlab-ci.yml.github/workflows/*.yml
実行Runner(共有/自前)ランナー(GitHub/セルフ)

GitLab を中心に開発を進めているなら自然な選択肢です。GitHub Actions と同様、利用しているソース管理基盤に合わせて選ぶのが基本です。

使いどころ・注意点

一つのプラットフォームに寄せる

CI/CD だけでなくレジストリ・レビュー環境・セキュリティスキャンまで同じ基盤に寄せると、権限・可視性・運用が一元化されて楽になります。自前 Runner を Kubernetes 上で動かすと、スケールと隔離を両立できます。CI/CD で使う変数・トークンは保護変数・最小権限で管理します。

総じて GitLab CI は、SCM から CI/CD・運用までを一体で完結できる統合 DevOps プラットフォームの中核機能です。

実装・運用の視点

GitLab CI/CDを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

GitLab 中心の DevOps

比較で見る軸

種別: CI/CD(GitLab 統合) / 提供元: GitLab / ライセンス: オープンソース+商用

導入後に効く点

セルフホスト/SaaS の両対応

先に潰すリスク

GitLab 前提

数字・仕様の読み方
種別
CI/CD(GitLab 統合)
提供元
GitLab
ライセンス
オープンソース+商用
登場
2015年

判断チェックリスト

  • 自社の用途が「GitLab 中心の DevOps / オンプレ統合環境」に近いか確認する。
  • 強みである「ソース〜CI/CD〜運用が一体」が本当に評価軸になるか確認する。
  • 注意点の「GitLab 前提」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

GitLab 中心の DevOpsオンプレ統合環境

向いている用途

こんな用途に向く

GitLab 中心の DevOpsオンプレ統合環境
公式サイト