Harness changes
Harness changes
harness.io

ECS Service Definition - enableExecuteCommand Support

 

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.

Screen Shot 2021-10-06 at 4.10.27 PM.png

Check out the Docs

Adding users without requiring to accept email invites

 

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

Permissions for application templates

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.

image.png

 

New

 

 

CF Deployment Behavior

 

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

Granular Access Control for Workflows & Pipelines CRUD

 

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!

API Support for Approvals

 

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!

Publish Pipeline Events to an HTTP Endpoint

 

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, or pauses during execution to any webhook endpoint. This will help users gain better visibility over their entire DevOps process.

image.png

The events can also be managed with GraphQL APIs.

Feature Flag - APP_TELEMETRY

check out the docs!

Deploying Helm Charts Experience Updates!

 

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

Screen Shot 2021-08-16 at 3.03.58 PM.png

Screen Shot 2021-08-16 at 3.05.04 PM.png

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

Compare environments to see the different services deployed

 

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.

image.png

Feature flag name: COMPARE_SERVICE_BY_ENV

For more details, check out the docs.

API Support for on-demand Artifact Source Cleanup

 

Improvement

 

 

Harness takes an hour or two to cleanup the artifacts deleted at the artifact repositories. We are introducing an API to trigger the cleanup job on an ad-hoc basis.

This improves the success rate of deployments since now, the artifact deleted at source will not appear in harness while initiating the deployments.

Check out the docs