My main use case for Harness is continuous deployment (CD), specifically for safe, automated deployment to production, especially in Kubernetes and cloud environments. For continuous deployment in my workflow, I use Harness by deploying a microservice to Kubernetes in production using a step-by-step workflow. Firstly, I code and build in GitLab, where the developer merges code to main, GitLab builds the app, runs tests, and creates a Docker image that is pushed to the container registry. GitLab triggers a Harness deployment with the new image tag. The second step is using the Canary strategy for deployment in Harness, where it deploys the new version to 10% of pods and partially shifts traffic to the new version. The next step is automated version monitoring, where Harness monitors key metrics such as error rates, latency, CPU, memory, and application logs. The fourth step involves decision and action; if metrics are healthy, Harness automatically promotes to 100%. If anomalies are detected, Harness automatically rolls back to the last stable version. The last step is approval and audit, where there is a manual approval step before full rollout for production and a full audit trail of who approved and when. As a result, production deployments are low risk and issues are caught within minutes, with no manual rollback needed and much higher confidence in releases.
Harness has been implemented in our organization for one of our clients for approximately 8 to 10 months. Harness is particularly utilized for our infrastructure provisioning pipelines and our RITM ServiceNow requests. With Harness CI/CD, one of our main use cases is using it as an infrastructure-provisioning pipeline. Harness allows us to have an end-to-end infrastructure pipeline, which connects our DevOps and our ServiceNow for governance and our custom portal, which we call an infrastructure-provisioning portal, and a central backend database through which we are able to provide a heterogeneous mixture of different resources including AWS, Databricks, Vault, IDMC, and GitHub repositories. Through this, we use Harness as the main platform where we are able to provision and manage all the pipeline executions as well as our requests that we receive for infrastructure provisioning. Our team primarily interacts with Harness using their Pipeline Studio. That is one of our finest use cases, and currently, we are also looking forward to integrating Harness or working within Harness so that we can do more pipeline-as-code type development.
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
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.
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.
My main use case for Harness is continuous deployment (CD), specifically for safe, automated deployment to production, especially in Kubernetes and cloud environments. For continuous deployment in my workflow, I use Harness by deploying a microservice to Kubernetes in production using a step-by-step workflow. Firstly, I code and build in GitLab, where the developer merges code to main, GitLab builds the app, runs tests, and creates a Docker image that is pushed to the container registry. GitLab triggers a Harness deployment with the new image tag. The second step is using the Canary strategy for deployment in Harness, where it deploys the new version to 10% of pods and partially shifts traffic to the new version. The next step is automated version monitoring, where Harness monitors key metrics such as error rates, latency, CPU, memory, and application logs. The fourth step involves decision and action; if metrics are healthy, Harness automatically promotes to 100%. If anomalies are detected, Harness automatically rolls back to the last stable version. The last step is approval and audit, where there is a manual approval step before full rollout for production and a full audit trail of who approved and when. As a result, production deployments are low risk and issues are caught within minutes, with no manual rollback needed and much higher confidence in releases.
Harness has been implemented in our organization for one of our clients for approximately 8 to 10 months. Harness is particularly utilized for our infrastructure provisioning pipelines and our RITM ServiceNow requests. With Harness CI/CD, one of our main use cases is using it as an infrastructure-provisioning pipeline. Harness allows us to have an end-to-end infrastructure pipeline, which connects our DevOps and our ServiceNow for governance and our custom portal, which we call an infrastructure-provisioning portal, and a central backend database through which we are able to provide a heterogeneous mixture of different resources including AWS, Databricks, Vault, IDMC, and GitHub repositories. Through this, we use Harness as the main platform where we are able to provision and manage all the pipeline executions as well as our requests that we receive for infrastructure provisioning. Our team primarily interacts with Harness using their Pipeline Studio. That is one of our finest use cases, and currently, we are also looking forward to integrating Harness or working within Harness so that we can do more pipeline-as-code type development.
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.