採用に向く条件
選ぶ理由
- ソース〜CI/CD〜運用が一体
- セルフホスト/SaaS の両対応
- DevOps 機能が充実
製品プロフィール
GitLab / CI/CD(GitLab 統合)
GitLab に統合された CI/CD。`.gitlab-ci.yml` でパイプラインを定義し、ソース管理から運用まで一気通貫。
基本情報
選定ガイド
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
採用に向く条件
事前に確認する条件
詳しい解説
GitLab CI は、GitLab に統合された CI/CD の仕組みです。GitLab 上のリポジトリに対して、ビルド・テスト・デプロイといった処理を自動で実行できます。
「結局なに?」を一言でいえば、GitLab に最初から組み込まれた自動化機能です。ソース管理から CI/CD、課題管理、コンテナレジストリまで一つのプラットフォームでまとめて扱える点が特徴です。
横にスクロール
パイプラインはリポジトリ直下の .gitlab-ci.yml で定義します。処理はステージ(例: build → test → deploy)に分かれ、同一ステージのジョブは並列、ステージ間は順に進みます。
test:
stage: test
script:
- npm install
- npm test
.gitlab-ci.yml を置くだけで始められ、設定が分散しにくい。| 観点 | GitLab CI | GitHub Actions |
|---|---|---|
| 前提基盤 | GitLab | GitHub |
| 統合範囲 | 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 プラットフォームの中核機能です。
実装・運用の視点
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
GitLab 中心の DevOps
種別: CI/CD(GitLab 統合) / 提供元: GitLab / ライセンス: オープンソース+商用
セルフホスト/SaaS の両対応
GitLab 前提
向いている用途