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.
Senior Software Engineer at a financial services firm with 10,001+ employees
Real User
Top 20
2025-04-28T09:03:00Z
Apr 28, 2025
Our primary use case for Harness ( /products/harness-reviews ) is as a deployment tool. Although I am not a DevOps engineer, my team uses Harness ( /products/harness-reviews ) for deployment purposes, handling configurations and onboarding applications to the Harness platform.
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.
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.
Engineering Technical Leader - SRE (Cloud/Kubernetes-Security) at Cisco
Real User
Top 10
2024-04-05T11:42:52Z
Apr 5, 2024
We use Harness for deploying Kubernetes clusters. It is a SaaS-based tool with a good graphical user interface. We can create workflows and deployment pipelines and easily visualize them. We can see the logs and understand where the pipeline is breaking. It's a highly customizable DevOps tool.
Harness offers a comprehensive toolset for automating deployment processes and enhancing software update efficiency. It's lauded for its CI/CD capabilities, feature flagging, and real-time deployment monitoring. Key features include an intuitive UI, secret management, and robust rollback functionalities, all contributing to improved productivity and reduced errors in DevOps environments.
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.
Our primary use case for Harness ( /products/harness-reviews ) is as a deployment tool. Although I am not a DevOps engineer, my team uses Harness ( /products/harness-reviews ) for deployment purposes, handling configurations and onboarding applications to the Harness platform.
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.
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.
We use Harness for deploying Kubernetes clusters. It is a SaaS-based tool with a good graphical user interface. We can create workflows and deployment pipelines and easily visualize them. We can see the logs and understand where the pipeline is breaking. It's a highly customizable DevOps tool.