GitLab
vs
Harness
vs
Decision Kit
Decision Kit
Harness.io Summary
Harness.io provides a service that automates the Continuous Integration, Continuous Delivery and what they call Continuous Verification stages of the Software Development Life Cycle (SDLC).
Their CD service is available both as SaaS and on-premises deployment (Connected On-Premises & Disconnected On-Premises). Harness CI (formerly Drone) is a self service CI offering. Drone Cloud is a free Continuous Integration service for the Open Source community.
The basic value prop for Harness is that it enables centralized teams to abstracts away some of the complexity involved in deploying both traditional and microservices based applications. Harness’ strengths tend towards newer microservices based architectures but they have support for vintage stacks like WebLogic and WebSphere.
Harness CI/CD
Like GitLab, Harness CI (formerly Drone) and CD also uses YAML files to define the steps of the CI/CD pipelines as well as all configuration for Harness CD. Unlike GitLab, Harness CI and Harness CD remain separate products.
Continuous Integration (CI)
The most notable feature of Harness CI is it’s container-first approach, using isolated containers to execute each step in the CI pipeline. Drone also offers the option to run pipelines directly on a host machine, in a Digital Ocean Droplet or in a MacStadium Virtual Machine. Drone packages and distributes Plugins as Docker containers that perform predefined tasks and are configured as steps in your pipeline. A list of available Plugins can be downloaded from their Plugin Marketplace.
Continuous Delivery (CD)
The most notable features for Harness CD are its structure of creating deployment pipelines from common workflow steps which promote service artifacts from environment to environment. This is the natural structure for deployment and delivery teams. Harness CD also provides central teams with easy ways to connect to shared infrastructure and provide common deployment templates for use by developmemt teams. Every configuration option for your application, services, environments and templates are encoded in YAML, but the basic components of that configuration can be done in UI. This configuration method provides strong auditability and when combined with a built in secret management capability provides many of the governance controls needed by large enterprises.
Harness Continuous Verification (CV)
Harness CV enables teams to connect application monitoring tools to their deployment process so that they can utilize automatic roll-back if application performance regresses during a deployment.
Recent Additions
Harness recently added Feature Flags (Continuous Features) and Cloud Cost Management (Continuous Efficiency) to its portfolio of products. At present both are only lightly integrated to the core Continuous Delivery Product.
Strengths
- Ability for deployment and delivery teams to templatize workflow steps and pipelines
- Ability for deployment and delivery teams to securely enable usage of infrastructure and environments by development teams
- Continuous Verification capability integrates with several monitoring tools and applies machine learning to detect anomalies and automate rollback of deployment.
- Configuration as Code - All CI/CD configuration is stored in YAML file for Git style collaboration
- Integrates with multiple source code (GitLab, GitHub, etc), ticketing (ServiceNow, JIRA) and monitoring (DataDog, New Relic) tools
- Centralized dashboards to understand the state of environments, applications and deployments
Gaps
- No built-in SCM capability - context switching from SourceCode to CI to CD tools (Harness CI and Harness CD remain separate) to take a pipeline from code to production.
- No commenting features so that deployment teams and developers can collaborate.
- Harness provides automated pipeline controls for continuous delivery but does not support manual Release Orchestration tools required by Release Managers outside of manual approvals required in automated deployments.
- Several out of the box integrations, but feedback from those systems is via a console type interface, making it harder to monitor tasks and to track down root cause of problems during deployment.
- No built in application or artifact security scanning- must rely on third party products. This lengthens time to secure, test and deploy.
- No Single Integrated DevOps Application: Harness is a tool that automates the Continuous Integration and Continuous Deployment stage of the Software Development Life Cycle. To extend functionality, integration with plugins is required.
- CI Security Accreditations: There is no information available on if Harness CI has achieved security accreditations such FedRamp and SOC 2
- Harness CI has not been recognized by Forrester Wave as a Continuous Integration leader
Feature Comparison
| FEATURES |
|
|
|---|---|---|
|
Free CI/CD with GitLab hosted or self-managed Runners
GitLab.com hosted runners allow you to use GitLab CI/CD completely free up to 400 build minutes for private projects and 50,000 minutes for public projects. Use your own runner for unlimited build minutes or special build environment requirements. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
Latest artifacts locked to prevent deletion
The latest artifact of a successful job and pipeline on any active branch, MR, or tag is automatically locked to prevent being deleted. This makes it possible to set an aggressive expiration policy to clean up older artifacts, reduce disk space consumption, and ensure the latest artifact is always available. This default behavior is configurable at the project level and can be disabled in project settings. |
|
|
|
Scheduled triggering of pipelines
You can make your pipelines run on a schedule in a cron-like environment. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Group-level variables
Define variables at the group level and use them in any project in the group. |
|
|
|
Customizable path for CI/CD configuration
You can define a custom path into your repository for your 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Deploy Boards
Deploy Boards offer 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. |
|
|
|
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 Premium can monitor your Canary Deployments when
deploying your applications with Kubernetes. Canary Deployments can be configured directly through |
|
|
|
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. |
|
|
|
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. |
|
|
|
Step folding for CI/CD logs
Collapse the job log output for each command. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 necessary 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. |
|
|
|
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. |
|
|
|
Run pipelines in the parent project for MRs from forks
A member of the parent project with appropriate permissions can run pipelines from a forked MR using the parent project’s pipeline configuration and runners. This adds another layer of security to verify that there’s no malicious activity in the forked MR that could affect the parent project. |
|
|
|
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. |
Multiple trigger types |
Supports 21 event triggers |
|
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 |
|
|
|
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. |
|
Auto Devops runs a pipeline, not just suggest one |
|
Advanced CI/CD configuration linter
The CI linter provide warnings and error messages when validating your |
|
|
|
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. |
|
|
|
GitLab Build Cloud Runners for Linux
GitLab SaaS-hosted runners for Linux run your CI job in its own virtual machine using GitLab Runner Docker executor. |
|
|
|
GitLab Build Cloud Runners for Windows (Beta)
GitLab SaaS-hosted runners for Windows run your CI job in its own virtual machine directly on ephemeral virtual machines. |
|
|
|
GitLab Build Cloud Runners for macOS (Beta)
GitLab SaaS-hosted runners for macOS enable you to directly run your CI/CD jobs for the Apple ecosystem on ephemeral virtual machines. |
|
|
|
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. |
|
browser search within the log at a time |
|
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. |
|
|
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
