Harness Open Source 完全ガイド：SCM・CI/CD・Gitspaces・レジストリを OSS 一択で完結させる方法

1. はじめに：なぜ今 Harness Open Source なのか

ツール乱立が生む見えないコスト

実際の開発現場では、GitHub でコードを管理し、Jenkins で CI を回し、Harbor でコンテナレジストリを運用し、Coder でクラウド開発環境を提供する——といった構成が広く見られます。それぞれが優れたツールである一方、管理先の分散はログイン先の増加・シークレット管理の複雑化・コスト積み上げを招きます。

SaaS 依存が続けば、ベンダーの価格改定やサービス終了リスクも無視できません。「頭の中の認知コスト」も含めた総合的なオーバーヘッドが、チームの生産性を静かに蝕んでいます。

Harness Open Source とは

Harness Open Source（旧称：Gitness）は、Harness Inc. が 2023 年に OSS 化した統合開発プラットフォームです。以下の 4 機能を単一バイナリ・Apache 2.0 ライセンスで提供します。

機能	概要
SCM	セルフホスト Git リポジトリ・PR レビュー
CI/CD	コンテナネイティブなパイプライン自動化
Gitspaces	ブラウザ完結型クラウド開発環境（CDE）
Artifact Registry	OCI コンテナイメージ・Helm Chart の中央管理

商用利用も完全無償、Docker Compose 1 コマンドで全機能が起動できる点が、他の OSS と一線を画すポイントです。

2. アーキテクチャ概要

シングルバイナリ設計の強み

バックエンドは Go で実装されており、コンパイル後はシングルバイナリとして動作します。これにより次のメリットが得られます。

起動の速さ：サーバー起動まで数秒
低リソース動作：小規模 VM やエッジ環境でも快適に稼働
エアギャップ対応：インターネット非接続環境へのポータブルな展開

フロントエンドは TypeScript + React の SPA として提供され、操作性は商用ツールに引けを取りません。

他 OSS との機能比較

機能	Harness OSS	Gitea	GitLab CE	Jenkins
SCM	✅	✅	✅	❌
CI/CD	✅	△	✅	✅
Gitspaces（CDE）	✅	❌	❌	❌
Artifact Registry	✅	❌	✅	❌

Gitspaces と Artifact Registry を同一プラットフォームで OSS 提供している点は、現時点で Harness Open Source のみです。

3. インストール・初期セットアップ

Docker Compose による最速起動

動作要件は Docker Engine と Docker Compose のみです。以下の docker-compose.yml で全機能が立ち上がります。

version: "3.7"
services:
  harness:
    image: harness/harness:latest
    ports:
      - "3000:3000"
    volumes:
      - harness_data:/data
    environment:
      - GITNESS_URL_BASE=http://localhost:3000
volumes:
  harness_data:

docker compose up -d

起動後は http://localhost:3000 にアクセスし、管理者アカウントを作成します。小規模環境では SQLite がデフォルトで使用されるため、追加の DB 設定は不要です。

Kubernetes（Helm）へのデプロイ

本番環境では Helm Chart を使用します。ベストプラクティスとして、外部 PostgreSQL と S3 互換ストレージ（MinIO 等）を分離して構成することを推奨します。

helm repo add harness https://harness.github.io/helm-charts
helm install harness harness/harness \
  --set global.database.postgres.enabled=true \
  --set global.storageClass=standard

4. SCM：セルフホスト Git リポジトリ

リポジトリ管理と移行

GitHub・GitLab からのリポジトリインポートはUIから数クリックで完了します。ブランチ保護ルールや CODEOWNERS ファイルによる承認ルールも設定可能です。

セキュリティ：Gitleaks 統合

実際の開発現場では、APIキーやパスワードの誤コミットはよくあるインシデントです。Harness Open Source には Gitleaks がビルトイン統合されており、シークレットを含むコミットをプッシュ時に自動ブロックします。

# Gitleaks 検出時のエラーイメージ
# error: secret detected: AWS_ACCESS_KEY_ID
# hint: push rejected to protect secrets

RBAC とアクセス制御

Space・Project・Repository の 3 層でロールを割り当てられます。OIDC/LDAP 連携によるシングルサインオンも対応しており、既存の ID 管理基盤と統合できます。

5. CI/CD パイプライン：ゼロから本番デプロイまで

パイプライン YAML の基本構造

Drone CI 互換の構文を採用しており、各ステップがコンテナとして独立実行されます。

kind: pipeline
type: docker
name: default

steps:
  - name: test
    image: golang:1.21
    commands:
      - go test ./...

  - name: build-image
    image: plugins/docker
    settings:
      repo: my-registry.internal/my-app
      tags:
        - latest
        - ${DRONE_COMMIT_SHA:0:8}
    when:
      branch:
        - main

トリガーはプッシュ・PR・スケジュール・手動実行をサポートし、ブランチ条件も柔軟に設定できます。

マトリックスビルドと並列実行

複数の OS・言語バージョンを並列テストする場合は、マトリックス設定を活用します。

matrix:
  GO_VERSION:
    - "1.21"
    - "1.22"
  OS:
    - linux/amd64
    - linux/arm64

シークレット管理

パイプライン内で使用するシークレットは Harness OSS のシークレットストアに保存し、YAML 内では変数参照のみ記述します。HashiCorp Vault や AWS Secrets Manager との連携も設定可能です。

6. Gitspaces：クラウド開発環境の標準化

CDE とは何か

Gitspaces は Cloud Development Environment（CDE） の実装です。GitHub Codespaces や Coder と同様に、ブラウザ内 VS Code でコーディングが完結します。Harness Open Source では、これをセルフホストで無償提供している点が差別化ポイントです。

devcontainer.json による環境定義

リポジトリルートに devcontainer.json を配置することで、チーム全員が同一の開発環境を瞬時に再現できます。

{
  "name": "Go Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/go:1.21",
  "postCreateCommand": "go mod download",
  "extensions": [
    "golang.go",
    "ms-azuretools.vscode-docker"
  ]
}

オンボーディング時間の短縮

段階的に理解を深めていくと、Gitspaces の最大の価値は「環境構築ゼロでコードを動かせる」点にあることがわかります。「README を読みながらローカルに依存関係をインストールする」から「ボタン一つで動く環境に入る」へ——新メンバーのオンボーディング時間を数時間から数分に短縮できます。

7. Artifact Registry：コンテナ・パッケージの一元管理

サポートするアーティファクトタイプ

OCI コンテナイメージ
Helm Chart
アップストリームプロキシ（Docker Hub / GCR / ECR のキャッシュ）

基本操作

# ログイン
docker login my-harness.internal

# イメージプッシュ
docker push my-harness.internal/my-org/my-app:1.0.0

# Helm Chart プッシュ
helm push my-chart-1.0.0.tgz oci://my-harness.internal/my-org

エアギャップ環境でのプロキシ活用

インターネット非接続環境では、Docker Hub などのアップストリームプロキシとして機能させることで、外部レジストリへの依存を排除できます。ベストプラクティスとして、本番環境では必ずアップストリームキャッシュを構成することを推奨します。

8. 実践：フルスタック開発フローの構築例

Next.js + Go API の Web アプリチームを想定した、Harness OSS を使った完全自動化フローを整理します。

ステップ	内容
1. リポジトリ設計	SCM で frontend / backend リポジトリを作成、RBAC を設定
2. 環境定義	devcontainer.json を各リポジトリに配置、Gitspace で即時起動
3. CI パイプライン	テスト → ビルド → Artifact Registry へイメージプッシュ
4. CD パイプライン	Helm で Kubernetes クラスタへ自動デプロイ
5. 完全自動化	PR マージ → CI/CD 連鎖 → 本番反映までノータッチ

すべてのステップが単一の Harness OSS インスタンス上で完結するため、ツール間の認証連携や Webhook 設定の複雑さが大幅に削減されます。

9. 運用・メンテナンスのベストプラクティス

バックアップ戦略

本番環境では以下の 2 点を定期バックアップします。

PostgreSQL：pg_dump による日次スナップショット
Git オブジェクトストレージ：S3 バージョニングの有効化

監視設定

Harness OSS は Prometheus メトリクスエンドポイントを標準で公開しています。Grafana と組み合わせることで、パイプライン実行数・成功率・レジストリ使用量を一元可視化できます。

アップグレード手順

Docker Compose 環境であれば、イメージタグを更新して docker compose pull && docker compose up -d を実行するだけです。マイグレーションは起動時に自動適用されます。

10. まとめ：Harness OSS を選ぶ理由と次のステップ

Harness Open Source が提供する価値を整理します。

コスト削減：SaaS 複数契約をゼロに近づけられる
ベンダーフリー：プラットフォームロックインからの解放
フルコントロール：データとインフラを自社管理できる
単一プラットフォーム：ツール間連携の複雑さを排除

将来的に規模が拡大した際は、同じ概念・YAML 構文のまま Harness SaaS へ移行するパスも用意されています。OSS で検証し、必要に応じてエンタープライズ機能を追加できる設計は、スタートアップから大規模チームまで対応できる柔軟性を持っています。

参加とリソース

GitHub：https://github.com/harness/gitness
公式ドキュメント：https://developer.harness.io/docs/open-source
Discord コミュニティ：ユーザー同士の知見共有・Issue 報告

段階的に理解を深めていくためには、まずローカルの Docker Compose 環境でセットアップを体験することを推奨します。既存の GitHub・GitLab 資産からのインポート機能も充実しているため、現行環境を壊さずに並行評価が可能です。

本記事は Harness Open Source の公式ドキュメントおよびリポジトリ情報をもとに執筆しています。バージョンアップにより仕様が変更される場合があるため、最新情報は公式ドキュメントをご確認ください。