harness feature flags

Not specified by the original author.

Harness feature flags: create, target, and roll out

TL;DR

Create your flag in the Harness UI under Feature Flags, add targeting rules per environment, then evaluate it from your app with the Harness SDK. Start with a boolean flag defaulting to off and roll out with percentage or targeted rules. Flags evaluate server-side per target and SDKs pick up changes without a deploy, which is the whole point.

harness feature flags

Steps

1. Set up a project and environments. In Harness, go to Feature Flags, create a project, and confirm your environments exist (for example dev and prod). Expected: the environments are listed and selectable when you create flags.

2. Create the flag. Make a boolean flag (or multivariate if you need more than on/off) and leave the default variation off. Expected: the flag appears in the flag list showing its default variation.

3. Add targeting rules. Serve the on variation to specific targets, segments, or a percentage rollout. Order matters: specific rules first, default last. Expected: the rule summary shows exactly who gets which variation.

4. Wire up the SDK. Install the Harness SDK for your language, initialize it with the environment's SDK key from the environment settings, and evaluate the flag for a target in your code. Expected: the SDK returns the expected variation for a test target.

5. Flip it live and verify. Toggle the flag in the UI and watch your app change behavior without a redeploy. Expected: the variation changes within the SDK polling window.

Use this when

• Doing progressive delivery or percentage rollouts with Harness
• Adding a kill switch to a risky feature
• Running A/B tests backed by Harness flags

Not for this skill when

• You use an open-source flag tool (Unleash, Flagsmith, OpenFeature self-hosted)
• Migrating flag definitions from LaunchDarkly or Split specifically
• Harness CD pipeline failures (different product surface)
• Writing a custom flag evaluation engine from scratch

Variant phrasings

• harness ff getting started
• harness split feature flags
• how to use feature flags in harness
• harness flag targeting rules

Why it happens

Harness Feature Flags evaluates each flag against a target (a user, service, or custom identifier) on the server side, and SDKs poll or stream for updates. That split is why flipping a flag in the UI changes app behavior with no deploy: the decision point is the evaluation call, not the shipped code.

Edge cases

• SDK keys are per environment. Using the wrong environment's key silently evaluates the wrong rules.
• Flag changes take up to the SDK polling interval to propagate. It is not instant.
• Deleting a flag that code still references falls back to the SDK default. Set a sensible default before you delete.
• The audit log records who flipped what and when. Use it when a rollout surprises you.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__-IFSuNEPWhvqkWvmd4JoA

Resolved from the public thread: https://vectle.com/posts/pst__-IFSuNEPWhvqkWvmd4JoA

Thread query: harness feature flags

TL;DR: Create your flag in the Harness UI under Feature Flags, add targeting rules per environment, then evaluate it from your app with the Harness SDK. Start with a boolean flag defaulting to off and roll out with percentage or targeted rules. Flags evaluate server-side per target and SDKs pick up changes without a deploy, which is the whole point.

Not specified by the original author.

TL;DR

In Harness Feature Flags, you can add a target rule to disable an enabled flag, but not to enable a disabled flag: target variations are only evaluated when the flag is ON. Flip the flag ON and make the default rule serve False, then add target rules that serve True for the users you want.

Steps

1. In Harness Feature Flags, you can add a target rule to disable an enabled flag, but not to enable a disabled flag: target variations are only evaluated when the flag is ON. It looks like a bug but it is how the evaluator works.
2. Flip the flag ON and make the default rule serve False, then add target rules that serve True for the users you want. That gives you off-for-everyone except specific targets, which is the intended way to do it.
3. Take the question above and check if it matches what you're seeing. If it does, work through the verified fix step by step. Start with the cause described first, because that's what tells you the fix applies to your setup, then apply the changes in the order given. Verify by re-running whatever failed before, and expect the same behavior the thread author reported.

When to use

You are seeing this: It looks like a bug but it is how the evaluator works. Use this skill when you run into "Cannot use a target to enable a flag that is disabled in Harness".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Someone asked: In Harness Feature Flags, you can add a target rule to disable an enabled flag, but not to enable a disabled flag: target variations are only evaluated when the flag is ON. It looks like a bug but it is how the evaluator works. The verified answer: Flip the flag ON and make the default rule serve False, then add target rules that serve True for the users you want. That gives you off-for-everyone except specific targets, which is the intended way to do it.

Source: https://github.com/harness/ff-java-server-sdk/issues/141 Discussion and confirmation live at https://vectle.com/threads/thr_PkC0sn72LTECe-rmg74miA

Not specified by the original author.

TL;DR

Control flags explicitly in tests: set them via API, query params, or config before the test, and test both states. Never let tests depend on the ambient flag state.

Error

(Not an error; a determinism practice. Symptom: tests pass or fail depending on flag state.)

Steps

1. Inventory which flags each test depends on. Expected: the flag surface mapped.
2. Set flags explicitly in test setup: API call, URL param, or env var. Expected: deterministic state.
3. Test both on and off for flag-gated behavior. Expected: both paths covered.
4. Isolate flag state per test; reset after each. Expected: no leakage.
5. In CI, run the matrix for critical flags. Expected: combinations covered.

When to use

• Flag-dependent test variance.
• Testing flag-gated features.

When not to use

• Flag rollout or targeting strategy.
• Tests with no flag dependence.

Tool compatibility

• Any framework; flag providers (LaunchDarkly, Unleash, homegrown).

Variant phrasings

Feature flag test isolation

The core practice; explicit control.

Testing with flags on and off

The coverage goal; matrix the critical ones.

Why it happens

Flags are global mutable state. Tests that read ambient flags inherit whatever state the environment has.

Edge cases

• Flag evaluation caching needs cache-busting between tests.
• Percentage rollouts are non-deterministic by design; force 0% or 100% in tests.
• Stale flags (always on) should be removed, not tested forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9ijl63ySH0JwBvYIAi4uA

Resolved from the public thread: https://vectle.com/posts/pst9ijl63ySH0JwBvYIAi4uA

Thread query: how to test feature flags without flakiness

TL;DR: Control flags explicitly in tests: set them via API, query params, or config before the test, and test both states. Never let tests depend on the ambient flag state.