HarnessとGitLabの比較 | GitLab.JP

このページでは、HarnessとGitLabを比較しています。それぞれの強みや不足部分を確認して、判断材料にしてください。

On this page

Summary

Harness.io is a Continuous Integration product that is available both as SaaS and on-premises deployment (Connected On-Premises & Disconnected On-Premises). The basic value prop for Harness is that it abstracts away some of the complexity involved in deploying both traditional applications and in microservices based applications. Harness' stregth is more in the newer microservices based architectures. Harness provides a good user interface to perform most Continuous Integration tasks and also connects with various SCM and CI tools.

Strengths

Gaps

Comparison

FEATURES

共有Runner、または個別RunnerでのCI/CDが無料

GitLab.comが提供する共有Runnerを使用して、プライベートプロジェクトでは毎月2000分までのCI/CDを、パブリックプロジェクトでは時間無制限のCI/CDを無料で利用できます。さらに、より高速なビルド、時間無制限のビルド、特殊な要件などに対応するために個別Runnerをセットアップして使用することもできます。

GitLab.comのプランを表示

統合されたCI/CD

GitLabにはCI/CD機能が統合されているので、CI/CDのために他のツールをインストールする必要はありません。GitLabのCI/CDを使用して、ウェブサイト(GitLab Pages)やウェブアプリケーションをビルド・テスト・デプロイできます。ジョブの結果はマージリクエストに表示され、簡単にアクセスできます。

CI/CDの詳細

CI/CD 水平自動スケール

GitLab CI/CDのクラウドネイティブなアーキテクチャでは、ワークロードが増加した場合に、新しいノードを追加することで簡単に水平方向にスケールできます。GitLab Runnerはパイプライン処理が開始されると、自動的に新しいコンテナを作成し、処理が完了して不要になったコンテナを削除します。これにより、CI/CDのコストを抑えることができます。.

GitLab CI/CDの水平オートスケーリングの詳細

CI/CD パイプラインダッシュボード

プロジェクトやグループ全体のパイプラインの履歴と現在のステータスをユーザーごとにカスタマイズできる単一のダッシュボードで視覚化します。

オペレーションダッシュボードでのプロジェクト間のパイプラインの詳細

チャットからデプロイ

チャットを使用して、ある環境(例: ステージング)から他の環境(例: 本番環境)へのデプロイができます。

スラッシュコマンドのドキュメントを確認

柔軟なパイプライングラフ

複数のジョブを直列、または並列に実行するパイプラインの構造は非常に複雑です。 GitLabでは単一のパイプライングラフですべてのジョブのステータスを表示できるので、 何が起こっているのかを簡単に確認できます。

パイプライングラフの詳細

成果物をブラウズ可能

GitLab CIを使用すると、外部サービスを必要としないで、GitLab内にジョブの成果物をアップロードできます。 これによって、アップロードした成果物をGitLabのウェブインターフェースで表示できます。

プロジェクト内のジョブアーティファクトの利用の詳細

パイプラインをスケジュール実行

cronのように、パイプラインをスケジュール実行できます。

GitLabでパイプラインがスケジュール実行される仕組の詳細

複数プロジェクトのパイプライングラフ

マイクロサービスアーキテクチャでは、パイプラインの設計はより複雑なものになります。 複数プロジェクトのパイプライングラフを使用すると、アップストリームとダウンストリームのパイプラインが、プロジェクトのトリガーを通して、どのように協調しているのかを表示することができます。

複数プロジェクトのパイプライングラフの詳細

保護変数

権限のあるユーザーだけが変数の値を取得できるように、変数を保護することができます。 「保護変数」は「保護ブランチ」で実行されているジョブからだけ取得できます。

保護変数の利用方法の詳細

デプロイメントプロジェクト

デプロイメントプロジェクトには、ビルドおよびテストされたリリースやリリースがデプロイされた環境など、デプロイしているソフトウェアプロジェクトが含まれます。

GitLabのプロジェクトの詳細

グループレベル変数

グループレベルで変数を定義し、グループ内のすべてのプロジェクトから使用することができます。

変数の設定方法の詳細

CI/CDの設定ファイルのパスを変更可能

プロジェクトのトップディレクトリにCI/CDの設定ファイルを置きたくない場合などに、設定ファイルのパスを独自に定義できます。

カスタムCI/CD設定ファイルの設定方法の詳細

CI/CDジョブをWindowsで実行

GitLab RunnerはWindowsをサポートしているので、ジョブをこのプラットフォームでネイティブに実行できます。 PowerShellやバッチファイルを活用することで、Windowsに基づくプロジェクトを自動で構築、テスト、デプロイすることが可能です。

WindowsにGitLab Runnerをインストール

macOSでCI/CDのジョブを実行

GitLab RunnerはmacOSをサポートしているので、このプラットフォーム上でネイティブにジョブを実行できます。 シェルスクリプトやコマンドラインツールを利用して、macOSベースのプロジェクトのビルド、テスト、デプロイを自動化できます。

macOSにGitLab Runnerをインストール

Linux ARMでCI/CDのジョブを実行

GitLab RunnerはARMアーキテクチャのLinuxをサポートしているので、このプラットフォーム上でネイティブにジョブを実行できます。 シェルスクリプトやコマンドラインツールを利用して、Linux ARMベースのプロジェクトのビルド、テスト、デプロイを自動化できます。

LinuxにGitLab Runnerをインストール

FreeBSDでCI/CDのジョブを実行

GitLab RunnerはFreeBSDをサポートしているので、このプラットフォーム上でネイティブにジョブを実行できます。 シェルスクリプトやコマンドラインツールを利用して、FreeBSDベースのプロジェクトのビルド、テスト、デプロイを自動化できます。

FreeBSDにGitLab Runnerをインストール

GitLab CI/CDでの各コマンドの実行時間の詳細

他のCIシステムの中には、ジョブ全体の実行時間に加えて、各コマンドの実行時間を表示できるものがあります。 GitLabにも同様の機能を実装するための検討が行われています。

この課題の詳細を確認

保護Runner

保護Runnerを使用すると、デプロイ用の秘密鍵のような、機密情報を保護することができます。 保護ブランチで実行されるジョブのみが、保護Runnerにアクセスできます。

この課題の詳細を確認

デプロイボード

GitLab Premium には Deploy ボードが付属しており、Kubernetes 上で実行している各 CI/CD 環境の現在の健全性とステータスを統合的に表示します。Kubernetesにアクセスすることなく、 最新デプロイのそれぞれのpodの稼働状況をGitLab内でシームレスに表示できます。

デプロイボードの詳細

定期的かつ手動でのインクリメンタルなロールアウトデプロイメント

GitLab を使うと、数個のわずかな Pod から開始して Kubernetes上に新しいバージョンのアプリケーションをデプロイし、全てが正常に機能している場合は割合を増やすことができます。これは、スケジュールに従って続行するか、入力のために一時停止して続行するように構成できます。

インクリメンタルなロールアウトデプロイメントの設定の詳細

カナリアデプロイメント

GitLab Enterprise Edition Premiumでは、Kubernetesにアプリケーションをデプロイしている場合は、 カナリアデプロイメントを監視できます。

カナリアデプロイメントの設定の詳細

最小限のCI/CDの設定

GitLab CI/CDは、Jenkinsのようなツールで同様のパイプラインを実行する場合と比べて、より少ない設定で済みます。

GitLab CI/CDの詳細

パイプラインのセキュリティ

保護ブランチで実行されるCI/CDパイプラインに対して、定義したセキュリティルールが守られているかチェックできます。 パイプラインのセキュリティは、手動で作成したパイプライン、再実行したジョブ、手動アクションにも適用されます。

パイプラインのセキュリティの詳細

外部のCI定義ファイルをインクルード

複数のプロジェクトで共通なジョブのテンプレートとして再利用するために、 外部のCI定義ファイルをインクルードできます。

外部ファイルのインクルードの詳細

CI/CDのログを折りたたんで表示

ジョブの各コマンドの出力ログを折りたたんで表示できます。

分所

外部リポジトリ用のCI/CD

GitLabに、GitHubやBitbucketなどの外部サービスがホストしているあなたのプロジェクトを接続し、 GitLab CI/CDのパイプライン機能を活用し、アプリケーションを簡単に構築、テスト、開発しましょう。

外部リポジトリ用のCI/CDの詳細

GitHub用のCI/CD

GitLabにGitHubがホストするあなたのプロジェクトを接続し、GitLab CI/CDのパイプライン機能を活用し、 アプリケーションを簡単に構築、テスト、開発しましょう。

GitHub 用の CI/CD の詳細

インタラクティブな Web ターミナル

Interactive web terminals allow you to connect to a running or completed Kubernetes, Docker, or Shell runner job and manually run commands to better understand what's happening in the system.

インタラクティブ Web ターミナルの詳細

リポジトリ毎の複数のパイプラインを定義

While GitLab has multi-project pipelines that give you a view across projects, each pipeline definition lives in a YAML file tied to a specific project. GitLab には今のところ 1 つの YAML ファイルに複数のパイプラインを定義する機能はありません。

この課題の詳細を確認

monorepo の明示的なサポート

特定のパスやファイルに変更がある場合にのみジョブを実行する機能は、単一のレポに多くのマイクロサービスを含むモノレポをサポートします。

CI/CD のみ/以外の実行の詳細

マージリクエストのパイプライン

Specify when you want jobs to run only when they are in a pipeline associated with a Merge Request. Make your pipelines more efficient by running only the neccessary jobs for Merge Requests.

マージリクエストのパイプラインの詳細

Pipelines for Merged Results

Keep master green. A special pipeline runs on the results of merged code before merging into master to detect changes that may be green on a branch but will fail master when merged.

Learn more about Pipelines for Merged Results

Merge Trains

Ensure an orderly and efficient flow of changes in a pipeline to target branches by queueing up pipelines in parallel, each building off the merge result of the previous pipeline. Squash-and-Merge is also supported together with Merge Trains.

Learn more about Merge Trains

Trigger pipeline on any event in code repository

Enables pipelines/workflows to be started based on when any defined event is executed in the code repository. For example, could run a workflow to send a welcome email on adding a new member to a repository or project.

Docs on GitLab triggerable events

Community powered workflows (configuration is code so are shareable)

GitLab pipeline (workflows) are defined as yml in repos and can be shared just like actions.

Any platform, any language, and cloud

Can run on any OS platform, for any language, and on any cloud provider

No configuration, infrastructure setup, or patching necessary

As a SaaS offering, can provide software development and delivery services without the need to set up the tool itself, infrastructure to run it, and to maintain it by patching.

Auto suggest pipelines to start with based on code language

Through language detection, auto suggest pipeline templates to run to help users quickly get a pipeline running.

Comes with many pre-defined pipelines

Offers many pre-defined pipelines that capture best practice and make it easy for a user to get started with each project for common languages, platforms, and configurations.

Connects the diff tools & services used during the SDLC

Can be used as a central glue to orchestrate, and connect data and outputs from your many different tools & services.

Matrix builds

Built-in ability to define and execute builds that automatically trigger a number of parallel jobs or pipelines based on a multitude of input variables. For example, building for 3 OS's at once, and for 3 different versions of libraries, would automatically be done in 9 parallel jobs. At GitLab, this is implemented using dynamic child pipelines.

Learn more about child/parent pipelines

Run shared Linux runners

Ability to run runners on a pool of shared Linux systems from the SaaS offering.

Run shared Windows runners

Ability to run runners on a pool of shared Windows systems from the SaaS offering.

in beta

Run shared macOS runners

Ability to run runners on a pool of shared macOS systems from the SaaS offering.

Pipeline status visible in pull/merge request

Status and results of pipeline runs are viewable at least in summary from the merge/pull request that they are part of.

Live streaming of logs from running pipeline

Ability to see live job logs (while the pipeline is running).

Search across all job logs

Search across all or more than one job log at once. Enables more efficient search for errors and other content of interest while troubleshooting or reviewing job output.

Download archive of all logs

Ability to download an archive of all job logs from a pipeline run in a single archive file. This is handy to enable analysis of the logs through another tool, or to send logs to someone who might not have access otherwise.

View raw logs in plaintext

Ability to get the plain text of a log, no mark up, to be able to share it or use it externally.

Multiple pipelines per repo

Ability to define multiple pipelines per code repository to enable either different processes to be run at different times, and/or to enable monorepos where there are multiple applications within one repo which need to be built and handled differently per application.

Reference actions/jobs in another repo

Ability to have pipelines/workflows reference and use actions/jobs from a repo different from the one it is being run from, without needing any installation.