The boolean flag is the core capability of any feature flag system, including Harness Feature Flags. It allows for two states, and is used in situations such as “turn the new feature on” vs. “turn the new feature off”, or “show button A” vs. “Show button B.” This is the most fundamental control available to the user in Harness Feature Flags.
Multivariate flags, in contrast to boolean flags, contain an unlimited number of states you can conditionally serve to an end user. Multivariate flags contain a key value pair assigned to any number of possible code paths. Commonly used for A/B testing and experimentation, multivariate flags can also be useful in situations, such as “archive every 30 seconds” vs” archive every 60 seconds” vs “archive every 90 seconds”.
User targeting and target grouping is the functionality that allows for serving different feature variations to different users, instead of all or nothing for the entire user base. Some simple situations in which this is used are serving different features to paid vs. free users, or serving beta users features that general users cannot access.
Progressive delivery is both a software delivery discipline as well as a specific feature offered by Harness Feature Flags. Progressive delivery provides the capability to release a change incrementally only to a subset of your audience, and then ramping the change up as you desire to introduce it more broadly to your users. For example, you can serve a new UI change to 10% of users, verify it, serve to 25% of users, verify, and so on until 100% of users have the feature. With Harness, this process can also be automated using pipelines so that users can set up the release progression and verification checkpoints, and let Harness take care of the rest. In Harness, this process can be automated through the use of Feature Release Pipelines.
SDKs for feature flags receive the configuration values from Harness in order to know what state of the flags to serve for each individual end session. There are two ways of doing this, polling (described here) and streaming. In polling mode, the SDKs will poll every 60s or longer to pull down changes from Harness, with the request being outbound from the SDK to Harness. In streaming mode, your SDKs will receive SSEs (Server-Side Events) from Harness in 500ms or less from the time of the change. Streaming mode allows for real-time updates but requires an inbound connection from Harness to be receivable by your SDKs or by the relay proxy.
Configuration as code lets you store and update your flag configuration as a YAML file inside the Git repo and Git branch of your choosing. With configuration as code, developers can update flags natively in Git while less technical stakeholders continue to use the UI. Configuration as code and UI changes work in parallel and Harness ensures they always reliably reconcile, meaning changes can be made in the UI or in code. It’s also a good way to ensure that multiple teams working together on a feature are in sync on status, history, and release workflows. All changes made through this GitOps workflow will be run through any associated Flag Pipelines.
Pipelines for Feature Flags allow you to easily build automated workflows that contain things like ServiceNow steps, Jira steps, notifications, triggering and more. These workflows let teams model business logic with feature flags, including scenarios like “Turn the flag on for 10% of your users, wait a day, request a Jira approval, turn it on for 25% of your users once approved and notify via Slack.” Harness lets automate the whole pipeline run, and trace the history via audit trail for each run. These pipelines can also be saved as templates for re-use for similar use cases in the future.
The same way Feature Release Pipelines allow for automated workflows to release features, Flag Pipelines let you enforce processes (i.e. approvals, notifications, etc.) on every flag change, such as changing flag state or targeting rules. Define a reusable pipeline with the steps you want to see, assign it to a flag, and you’ll instantly have governance that applies regardless of the flag change source: GitOps, API, or the UI.
Flag scheduling, as part of feature flag pipelines, lets you schedule workflow automations to happen either as a pre-configured one time fixed event or on a recurring basis. Using flag scheduling, you are able to have Harness run a pipeline workflow that increments a flag value by 10% every 24 hours starting on Friday at 9pm, for instance.
Harness enables you to save Pipeline automations as Templates to create re-usable logic and Harness entities such as Steps, Stages, and Pipelines in your Pipelines. You can link these Templates in your Pipelines or share them with your teams for improved efficiency. These templates enhance developer productivity, reduce onboarding time, and enforce standardization across the teams that use Harness.
The entire feature flag data model and all meta data are easily exposed to you via our custom dashboard and analytics (built on Google Looker). We ship out of the box dashboards that provide full visibility, but you can also easily edit these dashboards to build any custom reports you want - or export any of the data at no extra charge. For those that want to get more granular, Harness also offers per-flag analytics and audit trails.
The open source relay proxy service serves two main purposes: an added layer of resiliency to protect against downtime; and as a single point of connection between the user system and Harness. Once set up, the relay proxy will cache all flag states as they’re evaluated and the user system will ping the relay proxy for state rather than the Harness server directly (users only have to maintain one open connector for Harness), and the Harness server will update the relay proxy any time a flag’s state has changed. In the unlikely event of downtime, users can rest assured that flags will evaluate to their last known state.
The use of feature flags naturally creates tech debt in the system. Usually, to get rid of that, it requires having to manually identify flags for removal, and then scheduling a sprint to remove the flags, often at the cost of new feature development. Harness makes it possible for you to identify in the feature flag dashboard which flags are likely stale and need to be removed, and can automate the removal of those flags in the code. Once run, Harness will automatically open PRs to help Developers make the time to deprecate stale flags, and you’ll be able to see the diff of the automated removal in your source code repo and run it through your normal CI/CD process to deploy.
Harness Feature Flags tightly integrates the Feature Flags and Service Reliability Management (SRM) experiences, giving you instant alerts at the feature level when service reliability violations are detected. While the services are separate from the features, this product integration correlates feature or change releases with service changes. Instead of relying on tracing the service and what could have triggered the violation, you can see which feature or change triggered the issue and resolve it immediately by taking action against the feature flag, such as turning it off. For example, when deploying a new feature that leverages existing services, performance could be good for a month, then suddenly one or more of those services start causing reliability issues. Rather than looking through logs to find out what might have caused the issues, Harness will alert you that it was the feature deployed a month ago that caused the issue, saving triage and resolution time.
Harness Feature Flags tightly integrates the Feature Flags and CI/CD experiences, allowing you to see, govern and build automations that span from your first commit all the way through to enabling the feature in production with your customers via a unified user experience. For example, you are able to build a workflow that deploys an application and then immediately make that feature available to 10% of your users (via feature flag automation) and expand from there This unified experience provides you the ability to view your production audit logs along with the ability to control builds, deploys and flag changes all in one place. This integration also provides end-to-end analytics and creation of custom dashboard views spanning build to deploy to release.
SDKs are installed in your application and manage Feature Flag evaluation. They receive the flag configuration from the Harness platform via either polling or streaming mode and then make decisions about which code paths to serve based on the user’s session.
Server SDKs provided for use with Harness Feature Flags are used for backend technologies and store the entire configuration set locally, cache flag evaluations, and never communicate with Harness other than to receive communication changes and to report metrics.
All SDKs supported by Harness are open source. Get an overview of our SDKs here.
We support the following server-side SDKs:
SDKs are installed in your application and manage Feature Flag evaluation. They receive the flag configuration from Harness via either polling or streaming mode and then make decisions about which code paths to serve based on the user’s session.
Client SDKs provided for use with Harness Feature Flags are used for front-end languages or in single-user contexts and, while they do cache evaluation decisions, they otherwise rely on Harness or the relay proxy providing an evaluation decision as they do not store the entire configuration locally.
All SDKs supported by Harness are open source. Get an overview of our SDKs here.
We support the following client-side SDKs:
Mobile SDKs supported:
Harness provides well-documented REST APIs for automation across our entire platform, including onboarding new teams and projects at scale. Our public APIs enable you to automate and manage your end-to-end workflow, and integrate Harness into your existing tooling.
Harness provides built-in access control features including authentication, authorization and auditing. It also allows you to enforce password policies, such as password strength, periodically expiring passwords, and enforcing two-factor authentication.
Harness makes it easy to provision users with Okta. By using Okta as your identity provider, you can efficiently provision and manage users in your Harness Account, Org and Project. Harness' SCIM integration enables Okta to serve as a single identity manager, for adding and removing users, and for provisioning User Groups. This is especially efficient for managing many users.
By using Azure AD as your identity provider, you can efficiently provision and manage users in your Harness Account, Org and Project. Harness' SCIM integration enables Azure AD to serve as a single identity manager, for adding and removing users, and for provisioning User Groups. This integration makes it more efficient when managing large numbers of users.
You can use OneLogin to provision users and groups in Harness. Harness' SCIM integration enables OneLogin to serve as a single identity manager for adding and removing users. This is especially efficient for managing large numbers of users.
Manage multiple projects for business units or divisions easily in Harness. Harness Organizations (Orgs) allow you to group projects that share the same goal. A Harness Project is a group of Harness modules and their Pipelines. You can add an unlimited number of Harness Projects to an Org. All Projects in the Org can use the Org's resources.
Create custom dashboards (built on Google Looker) to access just the information you need. The Dashboard allows you to organize, explore, and present structured data logically. You can use this data to improve deployments and to inform and improve your operations and business decisions.
Harness supports various industry standards with regards to compliance and data privacy, including SOC2, ISO-27001, CSA Star, GDPR, and CCPA. Full details can be found at the link above.
Harness supports Single Sign-On (SSO) with OAuth 2.0 identity providers, such as GitHub, Bitbucket, GitLab, LinkedIn, Google, and Azure. These integrations allow you to use an OAuth 2.0 provider to authenticate your Harness Users. Once OAuth 2.0 SSO is enabled, Harness Users can simply log into Harness using their GitHub, Google, or other provider's email address.
Harness supports Single Sign-On (SSO) with SAML, integrating with your SAML SSO provider so you can log your users into Harness as part of your SSO infrastructure.
Harness supports SSO with LDAP implementations, including Active Directory and OpenLDAP. Integrating Harness with your LDAP directory enables you to log your LDAP users into Harness as part of Harness' SSO infrastructure. Once you integrate your Harness account with LDAP, you can create a Harness User Group and sync it with your LDAP directory users and groups. The users in your LDAP directory can then log into Harness using their LDAP emails and passwords.
Harness provides support for 2FA throughout the Harness Software Delivery Platform, with enforcement both at the individual user account level and at the account-wide (all accounts) level. 2FA setup with Harness is easy, using a smartphone-based process using QR codes for initial setup and username/password for all subsequent logins once configured.
Harness Audit Trails provide the visibility needed to meet organizational governance needs and prepare for external audits. With Harness Audit Trails, you can view and track changes to your Harness resources within your Harness account with data stored from up to two years prior. Without this data, developers are forced to manually compile information for audits.
Harness Policy as Code is a centralized policy management and rules service that leverages the Open Policy Agent (OPA) to meet compliance requirements across software delivery and enforce governance policies. Policies are written as declarative code, so they are easy to understand and modify, enabling teams to have autonomy over their processes with oversight and guardrails in place to prevent them from straying from standards. Teams can use Policy as Code to implement global governance policies across all releases, and combine with Pipeline Governance for policies to be implemented on a per-release basis. Follow this tutorial to implement policy-based governance in Harness Feature Flags.
Harness provides fine-grained RBAC to enforce separation of duties and control what user groups are granted access to specific resources based on assigned roles. This allows businesses to protect their data and key business processes through company-set rules and roles. Built-in roles are available by default to quickly create the desired permissions at the account, organization, and project level within Harness, as well as the ability to create custom roles for additional flexibility based on business needs that fall outside of the scope provided by default roles.
Harness Pipeline Governance measures how compliant your feature release pipelines are compared to your regulatory and operations standards. As a deployment pipeline is triggered within Harness, the deployment can require approval before releasing to production based on a “score” that indicates how compliant a given pipeline is before approving - this “score” is made up of individual weighted tags that, together, determine the level of compliance.
Harness Audit Trails provide the visibility needed to meet organizational governance needs and prepare for external audits. With Harness Audit Trails, you can view and track changes to your Harness resources within your Harness account with data stored from up to two years prior. Without this data, developers are forced to manually compile information for audits.
Harness provides a flexible hosting model that allows for full SaaS implementations, full on-premise implementations, and hybrid implementations. These flexible models allow companies with a variety of security requirements to use Harness Feature Flags.
Hosting includes:
Those using open source and source-available products from Harness can access community.harness.io to leverage our community-supported knowledge base contributed to by both Harness staff and Harness users.
Harness standard support, included for all Harness customers on a paid contract, includes coverage from 9am to 5pm Monday through Friday, with response times indicated in the table below based on the severity of the need. Support entitlements are provided for two named admins for each customer.
Harness standard support, included for all Harness customers on a paid contract, includes coverage 24 hours a day, 7 days a week, with response times indicated in the table below based on the severity of the need. Also included at the Premier support level are Zoom-based communication as well as post-incident reports. Support entitlements are provided to all customer staff.