Harness vs GitLab

GitLab compared to other DevOps tools

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

Free CI/CD with shared or personal Runners

GitLab.com has shared Runners that allow you to use GitLab CI/CD completely free up to 2000 build minutes for private projects and unlimited for public projects. Alternatively, you can set up your own Runner for faster build processing, unlimited build minutes, or special requirements.

Explore GitLab.com offerings

Built-in CI/CD

GitLab has built-in Continuous Integration/Continuous Delivery, for free, no need to install it separately. Use it to build, test, and deploy your website (GitLab Pages) or webapp. The job results are displayed on merge requests for easy access.

Learn more about CI/CD

CI/CD Horizontal Autoscaling

GitLab CI/CD cloud native architecture can easily scale horizontally by adding new nodes if the workload increases. GitLab Runners can automatically spin up and down new containers to ensure pipelines are processed immediately and minimize costs.

Learn more about GitLab CI/CD Horizontal Autoscaling

CI/CD Pipelines Dashboard

Visualize the history and current status of pipelines across projects and groups all in a single dashboard that can be customized for each user.

Learn more about Cross-Project Pipelines in the Operations Dashboard

Deploy from Chat

Deploy from one environment (e.g. staging) to any other (e.g. production) from Chat

Read the documentation on Slash commands

Comprehensive pipeline graphs

Pipelines can be complex structures with many sequential and parallel jobs. To make it a little easier to see what is going on, you can view a graph of a single pipeline and its status.

Learn more about pipeline graphs

Browsable artifacts

With GitLab CI you can upload your job artifacts in GitLab itself without the need of an external service. Because of this, artifacts are also browsable through GitLab's web interface.

Learn more about using job artifacts in your project

Scheduled triggering of pipelines

You can make your pipelines run on a schedule in a cron-like environment.

Learn how to trigger pipelines on a schedule in GitLab

Multi-project pipeline graphs

With multi-project pipeline graphs you can see how upstream and downstream pipelines are linked together for projects that are linked to others via triggers as part of a more complex design, as it is for micro-services architecture.

Learn more about multi-project pipeline graphs

Protected variables

You can mark a variable as "protected" to make it available only to jobs running on protected branches, therefore only authorized users can get access to it.

Learn how to use protected variables

Deployment projects

A deployment project holds the software project you are deploying: releases that have been built and tested, and the environments to which releases are deployed.

Learn about GitLab projects

Group-level variables

Define variables at the group level and use them in any project in the group.

Learn how to configure variables

Customizable path for CI/CD configuration

You can define a custom path into your repository for your CI/CD configuration file.

Learn how to configure a custom CI/CD configuration file

Run CI/CD jobs on Windows

GitLab Runner supports Windows and can run jobs natively on this platform. You can automatically build, test, and deploy Windows-based projects by leveraging PowerShell or batch files.

Install GitLab Runner on Windows

Run CI/CD jobs on macOS

GitLab Runner supports macOS and can run jobs natively on this platform. You can automatically build, test, and deploy for macOS based projects by leveraging shell scripts and command line tools.

Install GitLab Runner on macOS

Run CI/CD jobs on Linux ARM

GitLab Runner supports Linux operating systems on ARM architectures and can run jobs natively on this platform. You can automatically build, test, and deploy for Linux ARM based projects by leveraging shell scripts and command line tools.

Install GitLab Runner on Linux

Run CI/CD jobs on FreeBSD

GitLab Runner supports FreeBSD and can run jobs natively on this platform. You can automatically build, test, and deploy for FreeBSD-based projects by leveraging shell scripts and command line tools.

Install GitLab Runner on FreeBSD

Details on duration for each command execution in GitLab CI/CD

Other CI systems show execution time for each single command run in CI jobs, not just the overall time. We're reconsidering how job output logs are managed in order to add this feature as well.

Read more on the issue

Protected Runners

Protected Runners allow you to protect your sensitive information, for example deployment credentials, by allowing only jobs running on protected branches to access them.

Read more on the issue

Deploy Boards

GitLab Premium ships with Deploy Boards offering a consolidated view of the current health and status of each CI/CD environment running on Kubernetes. The status of each pod of your latest deployment is displayed seamlessly within GitLab without the need to access Kubernetes.

Learn more about Deploy Boards

Timed and manual incremental rollout deployments

GitLab can allow you to deploy a new version of your app on Kubernetes starting with just a few pods, and then increase the percentage if everything is working fine. This can be configured to proceed per a schedule or to pause for input to proceed.

Learn more about configuring incremental rollout deployments

Canary Deployments

GitLab Enterprise Edition Premium can monitor your Canary Deployments when deploying your applications with Kubernetes.

Learn more about configuring Canary Deployments

Minimal CI/CD configuration

GitLab CI/CD requires less configuration for your pipelines than other similar setups like Jenkins.

Learn more about GitLab CI/CD

Pipelines security

The ability of running CI/CD pipelines on protected branches is checked against a set of security rules that defines if you're allowed or not. It includes creating new pipelines, retrying jobs, and perform manual actions.

Learn more about pipeline security

Include external files in CI/CD pipeline definition

You can include external files in your pipeline definition file, using them as templates to reuse snippets for common jobs.

Learn more about including external files

Step folding for CI/CD logs

Collapse the job log output for each command.

Documentation

CI/CD for external repo

Connect your projects hosted on external services (like GitHub or Bitbucket) and leverage the power of GitLab CI/CD pipelines to build, test, and deploy your applications easily.

Learn more about CI/CD for external repositories

CI/CD for GitHub

Connect your projects hosted on GitHub and leverage the power of GitLab CI/CD pipelines to build, test, and deploy your applications easily.

Learn more about CI/CD for GitHub

Interactive Web Terminals

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.

Learn more about Interactive Web Terminals

Define multiple pipelines per repo

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. Today, GitLab lacks the ability to define multiple pipelines in a single YAML file.

Read more on the issue

Explicit support for monorepos

The ability to execute jobs only/except when there are changes for a given path or file support monorepos where many microservices are contained in a single repo.

Learn more about only/except CI/CD execution

Pipelines for Merge Requests

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.

Learn more about Pipelines 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.