Background
Coming out of the Design Sprint, we are ready to start building the connecting components needed to make GrowthBook the canonical experiment control plane.
For simplicity/expediency, we have decided to build these components in the Test Kitchen UI Node.js application which is responsible for generating the API endpoints consumed by Varnish, MediaWiki, etc.
Description
This epic introduces GrowthBook as the canonical experiment configuration control plane for Test Kitchen while maintaining backward compatibility with existing Test Kitchen UI (TKUI) experiment configurations during a short transition period.
The Test Kitchen UI backend will be refactored to implement an experiment configuration delivery service that:
- polls experiment configuration from GrowthBook
- validates those experiments configurations for compatibility
- adapts them into Test Kitchen’s API contract
- stitches them with existing TKUI-configured experiments
- serves stitched output via the existing /api/v1/experiments?format=config&authority=varnish and /api/v1/experiments endpoints consumed by Varnish and MediaWiki respectively
During the transition, the service will support dual experiment sources:
- GrowthBook (new canonical source)
- Test Kitchen UI (existing source)
The temporary stitching layer should combine experiments from both sources into a single response with defined conflict resolution rules and source-aware diagnostics. It is temporary migration infrastructure.
Once GrowthBook-based experiment delivery is validated (including correct SDK behavior and event decoration), TKUI experiment authoring will be disabled and replaced with a read-only view backed by GrowthBook and past TK-registered experiments will be read-only. The stitching logic will then be removed, leaving a single-source GrowthBook-only experiment configuration service.
Goals
- Introduce GrowthBook as the upstream experiment configuration source
- Build a backend service that validates and adapts experiment config for Varnish/MW
- Support dual-source experiment configuration during migration
- Provide observability and diagnostics for experiment configuration delivery decisions
- Safely deprecate TKUI experiment authoring/updating after GrowthBook integration validation
Out of Scope
- Rewriting the TKUI frontend beyond disabling authoring
- Changing the Test Kitchen SDK contract (unless required)
- Introducing distributed config infrastructure (i.e., multiple services, decoupling, event-driven config propagation, global config replication, dedicated config storage systems, etc)
Technical Notes
Our current experiment API logic is concentrated in:
- /experimentController.js
- should eventually call one backend configuration service, not raw experiment retrieval/formatting logic
- service/experimentService.js currently mixes:
- source loading
- time/status filtering
- contextual attribute attachment
- progress calculation
- response transformation
- util/experimentUtil.js currently handles:
- query param validation
- consumer-specific response adaptation
The proposed refactor of TKUI in this epic will be about pulling responsibilities out of those files into clearer service boundaries.
Proposed order of operations:
- Create canonical model
- Extract TKUI source loader from experimentService.js
- Add GrowthBook client + poller
- Add GrowthBook and TKUI validators
- Add GrowthBook and TKUI canonical adapters
- Implement stitcher
- Refactor controller/API to call one configuration service
- Add diagnostics + observability
- Disable TKUI authoring
- Remove stitcher later
Supporting Documentation
- PRD - T420529: FY25-26 SDS2.3.1 Field of Dreams - GrowthBook connection components
- Miro << design sprint architecture diagrams
- SDS2: Experimentation Platform FY25/26 - https://docs.google.com/document/d/1E_fsuy5rjQGIUoOGXWoiVSk4GhZAXI7zN0lT0m9AAL0/edit?tab=t.2mc7zhvxb50k#heading=h.48hxghbn2xko
- Design Sprint Tracker - https://docs.google.com/document/d/1UJK9rn7X08q7tGEpp-a67TYZBUtKf1u1c1gIh45GTNY/edit?tab=t.ch58e8mq0co