FeatureBase

[PROTOTYPE]

Managing the Feature Lifecycle

FeatureBase is an application designed to manage the entire feature lifecycle, from conception through maintainence, versioning and deprecation. The app works as an in-house system supporting all stages of feature development, used by product managers, developers, QA, and devops.

Prototype implementations are written in React / Node / MongoDB (feab-js) and Rails / PostgreSQL (feab-r).

The system is accessed through an administration portal, a JSON API, and in-memory databases. It integrates with external systems such as JIRA, github, and analytics tools. The admin portal captures feature definitions, screen designs, status, and development components, and can serve as a live dashboard of feature performance. The API can be used by developers and QA for build/test, and devops in production.

Features are associated with a given application Role and functional Domain. Roles describe the type of user acting on your system; domains group your features along functional lines. They are discussed below.

Feature lifecycle stages are defined as

1. gestation
2. development
3. staging
4. production
5. deprecated

Team Members

This table describes how product team members will interact with the FeatureBase system over the lifecycle stages.

Member Role	Gestation	Development	Staging	Production	Deprecated
Product Manager	Feature definition Admin interface		Gradual roll-out A/B testing	Analytics A/B testing User support	Replacement planning
Developer	JSON representation of feature data Automated test templates Component mappings Dependencies	Build-time integration Feature toggles			Code removal
QA	Test plans	Feature verification	Integration testing	Bug tracking
Dev Ops	Deployment strategy Runtime requirements		Runtime integration	Measurement Runtime access

Implementation Details

System Access

The system is designed as a stand-alone app that's accessible by product managers and developers, and at runtime in a production system. At build time developers can integrate JSON API calls to extract feature toggle, for example, which can be inserted into code. At runtime feature data can be loaded into memory, accessible by production system through Redis, for example.

Feature data can be managed to fit into a small memory footprint. This allows ease of use for developers, and fast, flexible availability at runtime in production.

Internally features are formatted using the Gherkin domain language, which is used as an interim input technique (until a user interface for browsing and editing is developed). This approach is also useful for testing and prototyping purposes, as we can include annotations for expressing more feature details.

DB Schema

The primary entities allow nested hierarchical relationships: Features, Roles, Domains.

Features

A prototypical example of a hiearchical feature is user authentication. This is represented as a general top-level feature, with children representing more detailed granularity.

• Authentication
  • Login
  • Registration
    • Confirmation
  • Forgot Password

Roles

These are the intended user roles for a given feature. In the following example, a premium user inherits from the user role, and the admin inherits from the former.

• Super User: top-level user with all privileges (e.g., support, QA)
  • Premium User: authenticated user will full feature access
    • Basic User: authenticated user with basic feature access
• Admin: administrative user (e.g., QA, devops)
  • Guest: an unauthenticated user

Domains

Domains represent groupings of features based on their business function.

Example

• Site: baseline features most apps support (e.g., authentication, navigation)
• Adhoc: feature set for baseline product offering
• Business Vertical: features targetting a specific business vertical