Harness helps us build a pipeline with containerized steps that isolates virtual machines, reduces DevOps-based drifts, and improves our process by integrating several security testing-related steps in the pipeline. Beyond that, it helps us remain regulatory and compliance adherent.

A specific example of how I use Harness for security testing or compliance in my pipeline involves the audits and certifications that our institution undergoes, such as SOC 2 and SOC 2 Type 2 certifications, as well as ISO 20001 certification needed for regulatory compliance in certain specific geographies where we operate. Harness comes in because it is compliant with these international regulations, and other larger institutions also use Harness for the same reason.

Harness offers several best features that I have worked with, including an intelligent caching system for dependencies and artifact building that allows for extremely short build times without extra bash scripting, a pipeline as code visual editor, and Harness Cloud along with small-lived virtual machines that we can run on Kubernetes.

The intelligent caching system has impacted my build times significantly by auto-caching dependencies and allowing smaller ephemeral runs to shorten build times without any need for detailed scripting, which has made a noticeable difference.

I would add that Harness has dedicated support for unit tests based on my experience, and this support is not restricted to only Java-based tests. I have seen support for Java tests, Scala, Ruby, and Kotlin, which helps us prevent flaky test management patterns.

Harness has positively impacted my organization as several teams have already migrated to it, and some are in the process of moving. It has reduced the dependency on one specific platform and has made it faster, with shortened build times and much faster deployments.

Harness can be improved by providing more clarity on the credits it issues for Harness Cloud, as it has a tiered pricing structure involving license and credit costs, which can get confusing. Additionally, there is a learning curve, as Harness is not currently an industry top-recommended solution, especially for teams coming from a Jenkins background.

For smaller teams, having features similar to GitHub Actions could be implemented by Harness, as this could really help the smaller teams who are moving to it.

I have been using Harness for three years now.

Harness is completely stable, and we are using it in production without facing any stability issues at all.

Currently, out of twenty teams that are supposed to adopt it, five or six have adopted Harness, and we have not seen any kind of scalability issues, such as slowness in performance or build time reduction, so I am satisfied with the scalability.

We have a direct line of enterprise support from Harness, and we have not faced any customer support issues, with tickets resolved in less than a four-day SLA.

We were using Jenkins before switching to Harness, as there was a lot of dependency, slowness, and build stability issues in Jenkins.

I cannot provide data on how much time has been reduced, but I believe the efficiency improvement is more than a twenty to thirty percent increase compared to Jenkins.

Before choosing Harness, we evaluated GitHub, GitHub Actions, GitHub CI, and CircleCI, in addition to Jenkins which we originally used.

My advice for others looking into using Harness is to perform a trade-off analysis between GitHub Actions, GitHub CI, CircleCI, and conduct a cost analysis. Harness is still new to the market and is cheaper, but Jenkins is completely open source and requires hosting, while Harness provides enterprise support for us to work with. Pros and cons need to be evaluated before adopting Harness. I am very happy with my current usage of Harness and would rate this review an eight out of ten.

In Harness, we are basically using Canary type deployments. We have applications, web applications, and web servers. Whenever we get the WAR file with 50 servers in a load balancer, Harness will deploy on the first server by automatically taking it out from the load balancer, deploying the latest JAR file, testing it at the back end, and giving us the result. Then our developer will test it from their end, and if both results are satisfying, they will run the test cases.

If both results are satisfying, then we proceed with the first half. The first server that is deployed will move back to the load balancer, and servers two through twenty-five will come out of it, deploy, test, and go back. It is all automatic. We just need to click proceed. Everything in Harness is configured and runs smoothly.

For CI/CD automation, I am using Harness only for continuous delivery, not the CI part. Harness takes care of maintaining compliance with security measures. We have dedicated IAM in AWS, with secrets and access. Harness itself will be in our private network, and we have dedicated user ID and credentials for each user.

For deployment, we are using Git for different projects. Through Git Bash, whatever changes we make locally, we push them to our Bitbucket. We have configured Git with the Bitbucket repository, and through Bitbucket, we try to merge everything. Once merged, the Jenkins pipeline gets triggered automatically. We check the Jenkins pipeline output to see whether the application is deployed successfully. We are also using Jenkins with Harness.

The best features in Harness are its user-friendliness and setup configuration. While the initial configuration can be difficult to configure the thresholds, check the artifactory, fetch the latest releases from the artifactory, and link everything in Harness, once completed, the configuration for any new application setup becomes easy. A fresher can also use it.

The main feature is that it asks for approval before proceeding ahead. It requires two approvals, asking 'Are you sure?' We have to manually enter 'approved' and then click on the approve button before it will proceed with the next step. This is important because sometimes, in a hurry, mistakes can be made by clicking approve multiple times, so this confirmation process is beneficial.

Harness setup and configurations could be made easier to configure, which would be helpful.

I have been working with Harness for these five to six years.

We have rarely faced issues with Harness tech support. We encountered one issue where the pipelines were unable to trigger, but they notified us from Harness itself that there was some downtime and they were trying to fix it. During their downtime, we do not use Harness and do not schedule any deployments.

Harness is fulfilling my expectations regarding the scalability aspect.

We have rarely faced issues with Harness tech support. When we encountered one issue where the pipelines were unable to trigger, they notified us that there was some downtime and they were working to fix it. During their downtime, we do not schedule any deployments.

It has different modules, and the working principle is quite different. We cannot compare as Harness is totally the continuous delivery tool, and Git is for the developer side.

I have it hosted on AWS Cloud.

I do not have any information about whether we purchased Harness through AWS Marketplace or from the vendor, as it is provided to us by our client.

I would rate Harness as a product and solution a nine. It works well for me.

I have not worked on the pricing, setup cost, or licensing cost of Harness, so I have no thoughts on the pricing aspect.

I cannot comment on third-party tools because we are not using any third party currently.

I am working with the cloud version with AWS and Harness.

I would recommend Harness as a solution to others if they are using infrastructure where load balancers and target groups are in the picture. Harness is very reliable. We can also deploy Kubernetes applications to Harness itself. In Kubernetes, compared to EC2, whenever we deploy the latest JAR file on EC2, we have to reboot the server for the latest change to get updated. In Kubernetes, whenever we deploy, we have to delete the pods, and new pods will come into picture with the latest update.

Harness takes care of it; whenever we deploy Kubernetes-based microservices applications, it will terminate the pods and spin up new pods with the latest version. The same Canary process is followed.

For my requirement, I am satisfied with what they are providing us in terms of features functionality. I rate Harness 9 out of 10.

Our primary use case for Harness is as a deployment tool. Although I am not a DevOps engineer, my team uses Harness for deployment purposes, handling configurations and onboarding applications to the Harness platform.

The features of Harness are valuable, supporting rolling deployments, basic deployments, and blue-green deployments with zero downtime. It offers multiple deployment styles, low timeouts, and clear logs with different views. Harness uses AI to suggest errors in case of deployment failures. It integrates well with HashiCorp Vault, seamlessly managing secrets such as database passwords.

When deploying multiple components to multiple environments, like production and BCP, failures sometimes occur. Improvements are needed when deploying one component to one environment.

I have been working with Harness for more than one year.

The deployment using Harness is a simple process, with features like automated rollback enhancing deployment security and reliability. Harness uses additional instances during deployment; if a new instance fails, it rolls back to the previous instance, ensuring zero downtime with rolling deployment.

Harness is stable.

As a SaaS product, Harness is scalable. Our entire organization uses it with hundreds of applications, and it supports this scale effectively.

We rely on our internal Harness support team for resolving issues, rather than external support from Harness.

Previously, we used Azure deployment and UrbanCode Deploy (UCD). We switched to Harness because it supports rolling deploy pipelines with zero downtime, unlike UCD, which required downtime for deployment.

I did not participate in Harness's initial setup as it was handled by a different team. I found the onboarding process straightforward.

Implementation teams such as DevOps engineers at our company handled the setup. We, as the application developer team, did not work on initial setup.

Before moving to Harness, we used Azure deployment. No other solutions were evaluated as our company, Wells Fargo, opted for enterprise support from Harness.

I rate Harness eight out of ten. Users should consider the need for deploying multiple components to multiple environments and the potential issues when doing so.

I used Harness for CICD, and it served as the release platform that our team used for Java applications. We do Java microservices, and we used it to deploy them.

Harness integrates all functions like execution pipelines, environment checks, and log monitoring in one place, making it convenient. It allows monitoring of deployment status and directs me to logs, making it easy to find bugs, saving us a lot of time.

Harness integrates all functions like execution pipelines, environment checks, and log monitoring in one place. It is very convenient since we have many microservices, so having one platform for all of them is beneficial. The dashboard allows me to monitor all core services' deployment status in one place, making it easier to find bugs and check logs.

Previously, when deploying a version that had been deployed successfully before, it sometimes failed upon trying again, which seems to be an intermittent issue about stability. I prefer the previous less compact UI version of Harness, which showed more details on the screen.

I used it for about a year, but the last time I used it was six months ago.

When integrating Harness with more than twenty applications in one place, it becomes less stable, causing improvements to be necessary.

When I integrated Harness to more than 20 applications in one place, it becomes less stable. Adding more services decreases stability.

I mainly get assistance from within my company, not directly from Harness' technical team.

Previously, I used uDeploy from IBM. We migrated from uDeploy to Harness due to an update in our company software, transitioning from TeamCity and uDeploy to Tekton and Harness. Harness is more user-friendly with a lower learning curve.

The initial setup was easy to do. I just needed to add a YAML file to my applications and get management approval.

I was in charge of implementing our company's Lightspeed integration with Harness and Tekton.

With Harness, the release process decreased from three or four hours to one or two hours, making deployments much quicker.

I would recommend Harness as it's better than uDeploy in terms of ease of use and functionality. It supports multiple pipelines, multiple environments, different service configurations, and has a user-friendly dashboard.

I's rate the solution eight out of ten.

We use Harness as a deployment tool. It allows us to define environments like OpenShift or Kubernetes or Linux servers.

It automates the pipeline system where users can trigger with the master branch. We use Tekton to run without any manual interaction. Once the build is done, it stores artifacts in JFrog, and Harness detects them automatically and executes deployment.

Harness has been much faster and user-friendly for the end user for deployment purposes. It allows us to do changes in the build stage during deployment, making processes more efficient.

Harness also allows for modifications at the YAML level, which is beneficial for our pipeline and deployment processes.

Harness starts integrating with organizations, making everything automated without the need for manual interruption.

It facilitates deployment by allowing a user to push their code into GitHub or Bitbucket and have it deployed without manual management intervention.

Even with automation, there's a requirement for manual change requests for approvals. If this is corrected, we could have a totally automated pipeline. Otherwise, we need to use GitLab or GitOps to trigger automatically with every commit.

I have been working with Harness for four to five months.

Harness is stable. There is no high latency or deployment delay, and it has proven to be reliable.

Currently, we are scaling up the pipelines with Harness, which provides functionality to achieve this without any significant issues.

There is a dedicated team within the organization to handle incidents and issues with Harness, so we don't need to rely on external support much.

We were previously using a different tool for deployments which had its limitations. Now, we use Tekton for continuous integration and Harness for deployment.

There were no significant challenges with the initial setup. We had a dedicated team for the implementation and were able to get support when needed.

For the implementation, there was a dedicated team handling Harness, which made the process streamlined.

Harness offers a user-friendly deployment experience with faster processes compared to the previous tools we were using.

I do not have information on the pricing, setup cost, and licensing as I am working for a client, and it is handled at the organizational level.

We have evaluated Jenkins and Tekton for continuous integration, yet Harness is used for deployment.

I recommend Harness to other users. As part of the engineering team, my role includes certifying products for applications, and Harness has proven suitable for our needs. I suggest adopting it based on usage requirements.

I'd rate the solution eight out of ten.