Harness changes harness.io

Improvement

Early Access

Based on the feedback received from our early adopters, we have enhanced the deployment freeze capability to support

1. Ad-hoc windows (Users will be able to easily set up freeze windows to stop deployments for the next 2 hours while doing critical demos).

2. Recurring windows (Easily set up freeze windows to avoid deployments from happening when the team is not around - no more weekend deployments).

3. Override a freeze window when you need to hotfix (Super admins (heroes) will be able to make sure that mission-critical deployments happen even when there is a freeze).

4. API Support (Now you can manage your freeze windows via APIs as well)

5. Now you have the flexibility to have freeze windows for services as well. You can block the deployments for some specific services across your environments or to Production/Non-Production environments.

Docs

Feature Flag to be disabled - TIME_RANGE_FREEZE_GOVERNANCE

Feature Flag to be Enabled - NEW_DEPLOYMENT_FREEZE

Improvement

What is the enableExecuteCommand?

Whether or not the execute command functionality is enabled for the service. If true, this enables execute command functionality on all containers in the service tasks.

Harness Enhancement

Harness users now have the ability to implement enableExecuteCommand as part of their ECS service definition.

Check out the Docs

Improvement

When users are added via LDAP sync or SCIM, there is no need for them to accept the email invite before they can login to Harness. This functionality has now been extended to users added via UI or API when the authentication method used is SAML.Users will still receive a notification email notifying them that they have been added to Harness but no action will be required on their part.

Lack of this feature was causing challenge to customers in automating the process of on-boarding new users and was also leading to increased support calls for lost emails.

This feature can be enabled using feature flag

AUTO_ACCEPT_SAML_ACCOUNT_INVITES

Users now have the ability to restrict access to specific templates that are part of the the applications to required user groups.

The existing Manage Template library permission will govern the access for only the account level templates.

A new permission type "Application templates" has been added to the Application permissions to govern the access for templates within applications.

With this, users can now ensure that application specific templates are not shared and can be accessed only by the respective teams!

Check out our docs for more details.

All user-groups that currently have account level template permission granted will automatically get the permission for all application templates to begin with. But users can choose to restrict this access.

New

Early Access

User can now tweak the behavior on how Harness deploys Cloud Foundry Application for Blue-Green, Canary and Basic Deployment Types.These behavior changes include naming behavior for the deployed services, rollback for the services during a failed deployment, and adding properties to applications.

Blue-Green Deployment

Canary Deployment

Basic Deployment

Feature Flag

CF_APP_NON_VERSIONING_INACTIVE_ROLLBACK

Another functionality we introduced is PCF CLI v7 Support, so users can leverage CLI v7 commands with the CF Command Step. Harness will execute deployment on CLI v7.

CF CLI 7

Feature Flag CF_CLI7

Improvement

Early Access

Now the admins can choose to give the access to Read/Edit/Delete specific workflows & pipelines to the users.

Checkout the Docs!

Feature Flag - WORKFLOWPIPELINEPERMISSIONBYENTITY

New

Harness users can now easily approve or reject their deployment pipelines with APIs. This will help automate the approval process and reduce the overall lead time. Users don't have to access the UI to manually approve/reject pipelines.

Checkout the docs!

Early Access

Users can now get event notifications about their deployment pipelines to any logging tool of their choice. They can set up events to be sent when the pipeline begins, completes, pauses or continues during execution to any webhook endpoint. This will help users gain better visibility over their entire DevOps process.

The events can also be managed with GraphQL APIs.

Feature Flag - APP_TELEMETRY

check out the docs!

Improvement

A few months ago, the Harness team released the feature: Helm Charts treated like an artifact source. The user can publish a Helm Chart and trigger it based off deployment. The Helm Chart is tracked like an artifact when Harness deployed it.

The new experiences we have introduced includes:

• API support to deploy services that have Helm Charts as an Artifact Source configured.
• A streamlined experience to configure Helm Charts as the Artifact Source
• Optimized Manifest collection to fetch Helm Charts from Helm Repos for Deployment selection
• User can provide multiple manifest sources for a service

Check out the docs for API : https://docs.harness.io/article/sbvn6uwcq1-deploy-helm-charts-using-api

Docs for Deploying Helm Charts: https://docs.harness.io/article/p5om530pe0-deploy-a-helm-chart-as-an-artifact

Happy Deploying!

Feature Flag - HELM_CHART_AS_ARTIFACT

Early Access

Users have multiple environments (Dev, UAT and Production) where services are deployed using Harness. Now we are helping you compare two environments and visually see what versions are services are available in each of them. This comparison is helpful to not only identify what services need to be upgraded but also very handy in trouble shooting issues. This feature is behind a feature flag and you can reach out to our customer success team for enabling it.

Feature flag name: COMPARE_SERVICE_BY_ENV

For more details, check out the docs.