2. Feature Flags

Date: 2022-06-01

Status

Accepted

Context

We know we need some way for processes to recognize that they’re working in a HACBS context or in an App Studio context. We’ve been referring to this need loosely throughout the first half of 2022 as “feature flags”.

Some examples:

We have been thinking about this flag as a HACBS-wide flag. We had assumed that the workspace itself would be HACBS enabled, or not. Perhaps the workspace would have an explicit type that would let us know we are looking at or operating in a HACBS workspace, and not an App Studio workspace.

Problem: workspaces don’t have a type useful for anything beyond initialization and they’re not going to have one. Features and APIs should be composable in a single workspace. A user might use a single workspace for lots of different activities - beyond just App Studio or HACBS. A workspace type is too restrictive and single-purpose.

We had also been considering that the “flag” could be inferred from the organizational hierarchy of the workspace - where, if the workspace was owned by an org that was owned by a tenant that was in some pre-configured list of HACBS-enabled tenants, then this workspace should be considered HACBS-enabled, workspace-wide.

Problem: we likely need to support the co-existence of HACBS-enabled workspaces and non-HACBS App Studio workspaces in the same tenant. Tenants are big enterprises, with lots of teams, and those teams have different adoption patterns. Some will want to be on App Studio, while others will want to be on HACBS. Although we don’t have real customer input on this, it is reasonable to expect that a single customer team may want to work on some projects in the HACBS feature set, and others in an App Studio feature set. Much more realistically, imagine the path for “turning on HACBS” at the tenant level. If you flip the switch at the tenant level, do all workspaces for all teams in the tenant suddenly change behavior? A tenant-wide setting is too coarse and disruptive to tenant teams that would appreciate independence.

Decision

Use “api discovery” to control the enablement of individual features in individual workspaces.

KCP provides the APIBinding resource as a way of letting the user declare that a particular API (read: CRD) should be made available in a single workspace. The user installs something in their workspace by creating an APIBinding. Our processes (controllers and hac) should query for the availability of a particular API they care about, and let their behavior be influenced by the existence or non-existence of that API.

Example: if the IntegrationTestScenario API is present in KCP for a workspace, then a process can know that the integration-service features of HACBS are enabled in the workspace.

Example: if the ReleasePlan API is present in the workspace, then a process can know that the [release-service] features of HACBS are enabled in the workspace.

Example: In hac, we’re implementing HACBS screens as part of the hac-dev plugin.

Open Questions

Consequences

References

Originally drafted in a google document