soluto/tweek

Tweek - an open source feature manager

tweek's Issues

meta data features - type specs

type Tag:String

type KeyMetaData{
    key:string;
    displayName:string;
    description?:string;
    type?:string;
    tags:string;
}

type SearchQuery{
    text:string;
    tags:string;
}

type MetaPropertyType{
    name:string;
    type:string | MetaDataType (inline);
    defaultValue?:string;
    description?:string;
}

type MetaDataType{
    name:string;
    baseType:string;
    allowedValues?:string[];
    compare?:string;
    validate?:string;   
}

type MetaRepository{
    //keys
    getKeyMetaData(key:string):Promise<KeyMetaData>;
    setKeyMetaData(key:string, meta:KeyMetaData):Promise;
    searchKeys(SearchQuery):Promise<KeyMetaData[]>;

    //props
    listProperties():Promise<PropertyMetaData[]>;
    setPropertyMetaData(property:string, meta:PropertyMetaData ):Promise;
    deletePropertyMetaData(property:string, meta:PropertyMetaData ):Promise;

    //tags
    listTags():Promise<Tag[]>;
    deleteTag(tag:string):Promise;

    //datatypes
    listMetaDataTypes():Promise<MetaDataType[]>;
    setMetaDataType(dataType:string, meta:PropertyMetaData ):Promise;
    deleteMetaDataType(dataType:string):Promise;
}

reduce save time

each tag adding, jpad or meta change, doing a pull and push, this operation causes a jpads build taking ~1-2 minutes.
as a mvp we will do 1 save for all changes (tags,meta,jpad) instead of save for each

Support for partitions

Partitions are way to organize rules on key.
Instead of having a flat view of rules, rules are organized/grouped by a partition.
A partition can be defined by using one or more properties.

// link to example

Only update rules if changes were made to the repo

Persist/save meta key data

• add meta client
• add new meta repository and mock implementation
• set new couchbase key space
• create couchbase meta repository implementation
• set server api (proxy in serverside to the couchbase)

both client and server should have mock/real meta provider

Support for custom compares in matcher

JPad Editor

• Basic Viewer.
• Ability to edit rules.
• Commit and publish.

Editor Experience

• View
  • Matcher
    • Properties
      • Simple fields
      • Other keys
    • Operators
      • Binary
      • Conjuction
  • Values
    • SingleVariant
    • MultiVariant
      • Barnouli
      • Weighted
• Edit
  • Cases
    • Delete
    • Add
    • Reorder
  • Matcher
    • Add condition
    • Delete condition
    • Properties
      • Simple fields
      • Other keys
    • Operators
      • Binary
      • Conjuction
  • Values
    • Change types
    • SingleVariant
    • MultiVariant
      • Barnouli
      • Weighted
• Meta Integration

Basic UX for backoffice

key meta data viewer and editor

• view display name and description
• view tags
• edit tags
• edit display name and description

include writing the reducer, add action types

Context writing endpoint for configuration service

Expose api for writing user data to context.
Suggest format:

POST /context/{identityType}/{identityId}/{key}
value

or

POST /context/{identityType}/{identityId}  
{key1:value1, key2:value2, ...}

Need to consider security (not MVP)

Add tests keys for smoke

suggested keys:

@tests
    simple
    nested
        key1
        key2
        key3
    multivarientkeys
        uniform
        bernoulli
        weighted
    matchers
        context
        not
        equal
        in
        comparison
        fixedcontextbasedkey
        keydependency
    rules
        multipleconditions
        multiplerules

need to add ownerType to jpad when creating Multivariant cases.

Testing couchbase driver

Couchbase is a document and kv db based on memcached.
It got the following advantages:

• Free and open source
• Extremely fast read throughput (for key-value)
• Persistence
• High availability - with cluster management and data-center replication
• Decentralized - all nodes are identical, no SPOF.
• Flexible data model (document db)
• Indexing and Querying capabilities
• Search support
• Map reduce views
• Nice management tools
• Not as used as Cassandra/Mongodb/Redis, but still used by big players
• Consistency - "Document access in Couchbase is strongly consistent, query access is eventually consistent" sounds good
• Should be easy to deploy on azure/docker cloud
• And there's an Enterprise version - support/qa/etc...

You can check the admin panel on:
http://couchbase-07cc5a45.b5501720.svc.dockerapp.io:8091/
username: tweek
pass:...

While we continue to use our "drivers" abstraction to decouple our app from the db, it might be the best solution to meet all our needs easily.

Most benchmarks are lies, but it should have very fast read performance -
http://www.datastax.com/dev/blog/how-not-to-benchmark-cassandra-a-case-study
http://www.couchbase.com/sites/default/files/uploads/all/Benchmarking-Couchbase-Server-for-Interactive-Applications.pdf

refactor tweek-rules structre

Current:

tweek-rules:
rules/{*keypath}.jpad
meta/{*keypath}.json
tags.json

suggested:

tweek-authoring:
dist/keys/{*keypath}.jpad
meta/keys/{*keypath}.json
         tags/{tagname}.json
         identities/{identity}.json (identity+properties)
         types/{type}.json

Add CI for project

migrate to node 6

Backoffice - deployment

fix integration tests

Add support for exist/not exist prop

Support for checking if key is not in context

//Key does not exists
{
     "MyProp":null
}
//Key exists
{
     "MyProp":{"$not": null}
}

Backoffice - allow to add new rules

Allow to add rules in ui

Get address for BlobRulesDriver from the management

backoffice CI speed

backoffice build time takes ~10 minutes due to npm i.
let's set a container with npm cache: https://github.com/tswicegood/docker-npm-cache
should speed it quite a lot.

create tweek client for js

should have simple client side cache to allow using it in sync code

Convert JPad Project to fsharp

Current C# wrapper is really not need and make code more complex with ugly interop tricks.
EntryPoints are pretty much the same as C# api:

type JPadParser(settings:ParserSettings) :
       Parse: (source:string)->IRule

type JPadGenerator :
       AddSingleVariant: (...params)-> generator
       AddMultiVariant: (...params)-> generator
       Build() -> RuleDefinition //(format*string)

Backoffice - save changes

Currently changes are not persisted to rules store.

create tweek client for c#

maybe should have simple client side cache to allow using it in sync code

basic layout: Set less infra files

Add Git Configuration to web.config

Currently, it's reading it directly from our code.

Authorization for reading configuration/writing context

Add UI tests for backoffice

Integrate search capability for meta data.

• integrate search engine
• implement first iteration of UI

Make driver loading and settings more modular and less code based

Both in services and integration tests.

Add data migration process

• - Batch process against devicestate table?
• - Ongoing - tweek feeder (need to check quality)

Prove "FF" incremental roll out is working (or not...)

Tweek value distributor currently create different distribution for different users based on the CreationDate of the user vs the experiment start-time.

In that way, by adding a new distribution, old users will get the old distribution values (retaining persistence) while new ones will get the new distribution values.

It was assumed that simply updating the rule instead of adding a new distribution is the same as reshuffle, but it's actually not the same because of the algo. (unless we replace the ruleid as well)

FF uses bernoulliTrial, which means a two variant distribution of [true|false] based on percentage.
It seems that in this case, since rule id, identity id, total bucket size (100) does not change, the users that got true will get the same values on increasing the "true" distribution.

In the case, FF rollout will work properly - meaning old users won't get "reshuffled".
We need to write a simple unit test to prove it, it might be that we already implement FF rollout by accident :)

Investigate backoffice production error

Backoffice fail to save rules

Add unit tests for backoffice

Security for backoffice

• SSL
• AD login

JPad format

Write a specification for JPad format.
Write a schema for validation.

Add safer mechanism for deleting rules

Should be deprecated once we implement proper diff view.

Support expression in "values"

Allow getting values from "context", can be useful for migration of calculated values.

Git Driver Implementation for rules

• Read data directly from git (MVP)
• Basic authoring capability for running tests.
• Setup git environment.

CI for synchronizing rules

Update Rules flow

Suggested flow:

• Tweek management service register hook on git repo to be notified on push
• Git hook on update send post to tweek management/admin service
• Tweek management service pulls all the data from
• Tweek management service does some validations/test based on admin settings
• Tweek management service bundle all the rules to single json
• Tweek management service send the rules to configuration service instance.
• Tweek Configuration service instance compile the rules
• If compilation works, configuration services sends 200 back to management
• Configuration service use db to propagate configuration changes to all instances.

Some notes
Tweek management service does not exist yet.
I think it will include in the future (Not all MVP):

• Rules editing front-end
• Rules validation constraints
• Configuration service settings (format/parser/etc...)
• Service Health check
• Other Management (authentication, etc...)
• Management service can use consul or zookeeper to sync and scale

Handle custom comparers parsing error

Error on the "target" value breaks the service which make sense, since we can easily prevent it.
Error on the value from the context fail the request.
It might be better to fail only the specific rule and log error, and return the other rules data to the agents.

Refactor "rules" terminology to jpad "cases"

set ci cd process to tweek backoffice

using travis-ci and docker

Reorganize folders

Current folder structure is a bit of mess.

better backoffice server logging

the server logs for tweek backoffice are currently in the docker service logs.
the docker logs are not user-friendly, slow, doesnt show past logs

Move all tests to xunit?

Currently, we use these frameworks for tests:
xunit
nunit 2.x
nunit 3.x

We also use FsCheck and FsUnit libraries for F# tests.
Both of them works properly with nunit 2.x and xunit, but not with nunit 3.x.
Since nunit 2.x will be obsolete and there are many breaking changes between 3.x and 2.x, it might makes sense to drop nunit in favor of xunit.

Split mutator to different lib