GitLab — 基礎、機能とCI/CD

GitLabとは？

GitLab — は、MITライセンスの下で提供されるフル機能のオープンソースDevOpsプラットフォームです。統合によってさまざまなサービスを組み合わせるGitHubとは異なり、GitLabはコード管理やコードレビューからCI/CD、モニタリング、セキュリティ、デプロイメントまで、開発ライフサイクル全体のための単一のツールを提供します。ほとんどのDevOpsタスクにサードパーティのサービスを必要としません。

GitLabの歴史は2011年、ウクライナの開発者による内部プロジェクトとして始まりました。最初のパブリックバージョンは2011年9月にリリースされ、2015年にGitLabはGitLab.com上の最初のプロジェクトとなり、クラウドホスティングを開始しました。2017年、GitLabは苦痛ではあるが教訓となる移行プロセスを実行しました。AzureからGoogle Cloudへのインフラ全体の移行はライブで行われ、一連のブログ記事で文書化されました。

GitLabのアーキテクチャは3つの主要コンポーネントで構成されています：GitLab Rails（Ruby on RailsのWebアプリケーション）、GitLab Shell（SSH経由のGit操作処理）、Gitaly（Gitデータアクセス用gRPCサーバー）。CI/CDはGitLab Runnerによって提供されます。これはビルドサーバーにインストールされ、分離された環境（Docker、Kubernetes、VirtualBox）でジョブを実行する独立したアプリケーションです。

GitLab CI/CD：パイプラインとランナー

GitLab CI/CD — は、プラットフォームの重要な利点である組み込みの継続的インテグレーション＆デリバリーシステムです。GitHub Actionsとは異なり、GitLab CI/CDは当初からアーキテクチャに組み込まれており、個別の設定は不要です。リポジトリルートに.gitlab-ci.ymlファイルを追加するだけで、すべてのプロジェクトが自動的にCI/CDを利用できます。

パイプラインは、順次または並行して実行されるステージで構成されます：build → test → deploy。各ステージにはランナーで実行される1つ以上のジョブが含まれます。ステージ内のジョブが失敗すると、ステージ全体が失敗とマークされ、デフォルトでは後続のステージは実行されません。以下はモバイルプロジェクトのパイプライン例です：

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runnerは複数のエグゼキュータをサポートしています：Docker（推奨）、Kubernetes、SSH、VirtualBox、Parallels。最も人気のあるオプションはDockerエグゼキュータで、各ジョブを個別のコンテナで実行します。ランナーは1つのプロジェクトに固有のものとして、またはグループ全体の共有（shared）として登録できます。GitLab.comは月2000分の制限付きで無料の共有ランナーを提供しています。

CI/CDの高度な機能

GitLab CI/CD は、手動トリガー（when: manual）、遅延トリガー（when: delayed）、並列実行（parallel: 5）、マトリックス、動的パイプライン（child pipelines）、マルチレベルパイプライン（parent-child）をサポートしています。これにより、モノレポ内の各モジュールのパイプラインを動的に生成したり、異なるAndroidアーキテクチャ（arm64、x86_64）の並列ビルドを実行するなど、複雑なシナリオを構築できます。

GitLab vs GitHub：主な違い

GitLabとGitHub — はGitプラットフォーム市場の2大競合ですが、その哲学とアーキテクチャは根本的に異なります。GitHubはオープンコミュニティ、統合のエコシステム、ソーシャル機能（フォーク、スター）に重点を置いています。GitLabは包括的なDevOpsサイクルに焦点を当て、計画から監視まですべてのツールをすぐに使える状態で提供します。

主なアーキテクチャ上の違い：GitLab — は開発者が全体をインストールする単一のモノリシックアプリケーションです。すべての機能（CI/CD、Container Registry、Security Scanning、Pages）が組み込まれており、インストール後すぐに動作します。GitHubはAPIを備えたプラットフォームであり、ほとんどの機能はサードパーティサービス（Travis CI、CircleCI、Jenkins、SonarQube）との統合によって実装されます。以下の表が主な特徴を比較しています：

GitLabとGitHubの選択はチームのニーズによって異なります。優先事項がゼロコンフィギュレーションでの迅速なデプロイとオープンコミュニティであればGitHubを選びましょう。インフラの完全な制御、セルフホステッドデプロイ、組み込みセキュリティが必要であればGitLabが適しています。Stack Overflowの調査（2024年）によると、90%の開発者がGitHub、33%がGitLabを使用しています（多くの場合両方のプラットフォームを同時に）。

Self-Managed GitLab：自社サーバーへのインストール

Self-Managed GitLab（旧称On-Premises）を使用すると、プラットフォームを自社サーバーにインストールし、データ、インフラ、稼働時間を完全に制御できます。これは、データをサードパーティのサーバーに保存できない金融セクター、政府機関、医療機関など、コンプライアンス要件のある組織にとって特に重要です。

GitLabのインストールはUbuntu、Debian、CentOS、およびDocker経由でサポートされています。公式のOmnibusパッケージには、Webサーバー（NGINX）、データベース（PostgreSQL）、キャッシュ（Redis）、Gitハンドラ（Gitaly）、バックグラウンドプロセスなど、すべてのコンポーネントが含まれています。最小要件：最大100名のチームで4 GB RAMと2 CPU。高負荷の大規模インストールでは、コンポーネントを別々のサーバーに分割することを推奨します。

# Omnibus経由でUbuntuにGitLab CEをインストール
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# パッケージのインストール
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# ステータスの確認
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLabにはCI/CDの分数制限がありません。すべてのランナーは組織が所有し、その能力は自身のハードウェアによってのみ制限されます。また、リージョン向けのGeoレプリケーション、監査ログ、IPブロック、企業LDAP/SAMLプロバイダーとの統合も利用可能です。GitLabは毎月（22日）新機能とセキュリティ修正を含むアップデートをリリースしています。

GitLabの組み込みセキュリティツール

GitLabのセキュリティはプラットフォームレベルで組み込まれており、パイプラインの各段階で動作する複数のスキャナーが含まれています。SAST（静的アプリケーションセキュリティテスト）はアプリケーションを実行せずにソースコードの脆弱性を分析し、Java、Kotlin、Swift、Python、JavaScriptを含む15以上の言語をサポートしています。DAST（動的アプリケーションセキュリティテスト）は実行中のWebアプリケーションを内部からテストします。

追加ツール：Container Scanningはベースレイヤーの脆弱性についてDockerイメージをチェックします。Dependency Scanningはプロジェクトの依存関係を分析し、既知のCVEについて警告します。Secret Detectionは誤ってコミットされたAPIキー、パスワード、トークンを検出します。Fuzz Testingは不正なデータを使用して自動テストを実行し、自明でないバグを発見します。すべてのスキャン結果は統合セキュリティダッシュボードに表示されます。

GitLabはコンプライアンスツールも提供しています。コンプライアンスダッシュボードは全プロジェクトの準拠状況を表示し、監査イベントは管理者と開発者のすべてのアクションを記録し、コンプライアンスフレームワークは特定のプロジェクトグループに設定ポリシーを強制的に適用できます。これにより、厳格なセキュリティ要件を持つエンタープライズ環境でGitLabは人気のある選択肢となっています。

Container RegistryとDependency Proxy

GitLab Container Registry — はCI/CDと統合された組み込みのDockerレジストリです。パイプラインでDockerイメージをビルドした後、環境変数CI_REGISTRYとCI_REGISTRY_USERを使用して即座にレジストリに公開できます。レジストリはpull-throughキャッシング、タグ付け、クリーンポリシー、レジストリ内での脆弱性スキャンをサポートしています。

Dependency Proxy — は外部レジストリ（Docker Hub、Quay、GCR）からのコンテナとイメージのキャッシングメカニズムです。パイプラインがubuntu:latestのようなイメージを要求すると、GitLabは最初にキャッシュを確認します。イメージが既にダウンロードされている場合は再取得されません。これにより外部レジストリの負荷が軽減され、パイプラインが高速化され、Docker Hubのレート制限から保護されます。

モバイル開発者向けに、GitLabはドキュメントやテストレポートをホスティングするためのGitLab Pagesを提供しています。テスト実行後、成果物（HTMLレポート、スクリーンショット、ログ）をPagesとして公開し、QAチームとリンクを共有できます。すべてが同じGitLabプロジェクト内に配置されるため、クラウドストレージにレポートをアップロードするより便利です。

GitLab APIとWebhook

GitLab API（RESTおよびGraphQL）は、プロジェクト、ユーザー、パイプライン、マージリクエスト、レジストリなど、プラットフォームのすべてのリソースへのアクセスを提供します。APIは自動化に使用されます：テンプレートからのプロジェクト作成、レビュアーの割り当て、パイプラインステータスの取得など。Webhookを使用すると、push、merge、Issue作成などのイベント時に外部システムにHTTP通知を送信できます。WebhookはMattermost、Slack、Telegram、内部監視システムと統合できます。

モバイルドキュメントのためのGitLab Pages

GitLab Pagesはリポジトリから静的なウェブサイトを自動的に公開します。モバイルプロジェクトでは、APIドキュメント、テストカバレッジレポート、lint分析結果のホスティングにPagesが便利です。公開はパイプライン成功後に自動的に行われます。.gitlab-ci.ymlにPages公開を含むデプロイステップを追加するだけです。結果はhttps://namespace.gitlab.io/project-nameで確認できます。