Featurevisor

Workflow

Projects

A Featurevisor project is intended to be used as a single standalone Git repository, separate from your application codebase.

Creating a project

The easiest way is to use the Featurevisor CLI using npx (Node.js).

Initialize a new Featurevisor project:

Command
$ npx @featurevisor/cli init

Installation

Afterwards, install the dependencies:

Command
$ npm install

Platform agnostic usage

While Featurevisor project itself depends on Node.js, your applications do not need to.

The idea is that a Featurevisor project will generate datafiles (static JSON files), which will later be consumed by applications using SDKs in different programming languages which do not need to have any ties to Node.js in any way.

Options for a project

A Featurevisor project can be initialized in multiple different setups, with:

We can visualize the possible setups in a table below:

EnvironmentsSetsCommand
1npx @featurevisor/cli init
2npx @featurevisor/cli init --example=no-environments
3npx @featurevisor/cli init --example=sets
4npx @featurevisor/cli init --example=environments

Further details on how best to choose your setup:

  1. Multiple environments, no sets: recommended setup, where rules for multiple environments are defined in the same feature definition.
  2. No environments, no sets: for very simple use cases, where you only have a single environment and no sets.
  3. Multiple environments, multiple sets: useful when you wish to use a Featurevisor project like a monorepo for multiple different definition trees (think like a monorepo of projects).
  4. No environments, multiple sets: handy for imitating each environment as a separate set, with incremental linear promotions.

Below we will go through option number 1 from the table above.

Directory structure

Command
$ tree .
.
├── attributes/
│   ├── country.yml
│   ├── deviceId.yml
│   └── userId.yml
├── datafiles/ (generated later)
│   ├── production/
│   │   └── featurevisor-all.json
│   └── staging/
│   └── featurevisor-all.json
├── features
│   └── showCookieBanner.yml
├── featurevisor.config.js
├── package.json
├── segments
│   └── netherlands.yml
├── targets
│ └── all.yml
└── tests
├── features
│   └── showCookieBanner.spec.yml
└── segments
└── netherlands.spec.yml

Project configuration

  • featurevisor.config.js: contains your project configuration. Learn more in Configuration page.

Building blocks

These are the directories where you will be defining all the building blocks for managing your features:

  • attributes/: contains all your attribute definitions
  • segments/: contains all your reusable segments, which work as targeting conditions
  • features/: contains all your feature definitions
  • targets/: contains your target definitions, which decide the datafiles that get built
  • tests/: contains all your test specs against your features and segments

Output

  • datafiles/: contains all your generated datafiles, which are meant to be consumed by SDKs in your applications

Git repository

While it is intended that a Featurevisor project should be hosted in a standalone Git repository, it is not a strict requirement.

Command
$ git init
$ git add .
$ git commit -m "Initial commit"

You can still use the CLI to manage your project without a Git repository, or as part of your larger application codebase (think a monorepo setup).

However, it is highly recommended to use a standalone Git repository to keep track of your changes and collaborate with others. Keeping it separate from your application codebase allows you to decouple your feature changes from your application code deployments.

Previous
Targets