Harness changes harness.io

You can now deploy artifacts from Artifactory to AWS Lambda.

For ECS blue/green deployments, you can now specify non-default listener rules when configuring your load balancer.

For more information, read our documentation.

Approval steps in a pipeline can now be executed on a certain condition (similar to execution steps). This improvement allows users to create more flexible pipelines and skip the approval process when deploying to non-regulated environments

For more information, read our documentation

Based on customers feedback, we improved the ServiceNow integration for approval purposes and added the following new functionality:

1. Users can now choose which ServiceNow fields can be used for approval. This provides a more custom and advanced way to set up the approval process if managed through ServiceNow

2. Honoring deployment windows- Harness approval process will respect ServiceNow deployment window and, upon approval, will proceed with deployment only within the allowed deployment timeframe.

For more information, read our documentation

For compliance and audit purposes, users can now export the entire deployment details (inc. execution order, variable details, logs, etc) to a JSON format and store the information in an external system that can be used to access the data outside of Harness

For more information, read our documentation

You can now destroy provisioned infrastructure with Terraform by specifying the Backend state file.

Read our docs for more info.

Harness users can now use passwords stored in secret managers when connecting to 3rd party tools, such as artifact and Git repositories, cloud providers, etc.
This will help to store and update passwords in a centralized place, and the system will always use the latest value when the connection is required

Harness PCF now supports deploying Docker images.

Harness supports a Firefox browser for using the product

This powerful new feature prevents users from starting an entire pipeline from the beginning in the event of a failure, allowing teams to resume execution from a specific stage.
In case a failure occurred during the deployment (but some stages finished successfully already), the user can fix the issue and continue the execution from that point only and do not need to start the execution from the beginning. This approach will help saving time and efforts, accelerating the delivery of the changes to production