Download the PHP package socloz/feature-flag-bundle without Composer
On this page you can find all versions of the php package socloz/feature-flag-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package feature-flag-bundle
FeatureFlagBundle
A bundle to manage feature flags & A/B tests
this bundle is not production-ready - some features have not been fully developed or tested
Dependencies
- Redis using phpredis
Feature flags
Features are defined in the application configuration. Features can be enabled/disabled :
- using the provided admin controller (global level),
- by your application (session level),
- using the provided front-end controller (session level),
- by adding a request parameter to the page url (page level).
A feature can have the following default state :
- disabled-always : the feature is disabled and cannot be enabled,
- disabled-hidden : the feature is disabled, and cannot be globally enabled. It can be enabled for development/testing purposes using the front-end session controller or the request parameter,
- disabled : the feature is disabled and can be enabled,
- enabled : the feature is enabled and can be disabled,
- enabled-always : the feature is always enabled, and cannot de disabled.
A/B Testing
A feature can have multiple variations. The list of variations is defined in your configuration file, and it is your responsibility to modify your templates according to those variations.
Variations are automatically chosen by the bundle, but can be changed :
- by your application (session level),
- using the provided front-end controller (session level),
- by adding a request parameter to the page url (page level).
The service provides a simple success/failure couting mechanism. You can also use your favorite external analytics service.
Configuration
The basic configuration is :
Other options :
socloz_feature_flag.options.redis.prefix: prefix for redis keys (default :socloz_feature_flag)
Using feature flags
Testing if a feature is enabled for the current user :
PHP
Twig
Enabling/disabling a feature for the current user :
PHP
Using A/B Testing
Getting the feature variation for the current user :
PHP
Twig
Couting transactions :
PHP
Analytics call :
Twig
Admin interface
The admin interface is located at /feature-flag/admin/features.
To use the admin interface, you must load the admin routes in routing.yml:
The twig template use Twitter Bootstrap CSS classes, but does not include Twitter Bootstrap.
You can override the layout by creating a app/Resources/SoclozFeatureBundle/views/layout-admin.html.twig file, such as :
You have to secure the admin route in your security.yml file :
Use whatever role is appropriate...
Front-end controllers
If you want to be able to switch features or variations for the current session, load the corresponding routes :
You can toggle a service for the current session using /feature-flag/{feature name}/enable and /feature-flag/{feature name}/disable.
You can change variation for the current session using /feature-flag/{feature name}/change_variation/{variation}.
The controllers redirect to the route configured as socloz_feature_flag.options.base.redirect (use route names).
You can display the feature state or variation using /feature-flag/{feature name}/status or /feature-flag/{feature name}/ab_status
Page-level toggles
You can change variation or toggle features using query string parameters :
socloz_feature_flag_{feature name}_enabled(0 to disable, 1 to enable)socloz_feature_flag_{feature name}_variation(add the variation name)
Google Analytics
The Google Analytics implementation expects that you use the async Google Analytics tag. If your tag looks like this :
everything is fine. If it does not look like it, analytics won't work.
A single custom variable (session level) is used for all features. Therefore, you have to use the same variation set for all your features,
and use the socloz_feature_flag.splitter.shared_random splitter (see below).
The custom variable can be configured using :
socloz_feature_flag.google_analytics.variable_id(id of the variable, default 1)socloz_feature_flag.google_analytics.variable_name(name of the variable, default socloz_feature_flag_variation)
Advanced configuration
All internal services can be overloaded :
Splitter service
Configuration : socloz_feature_flag.services.splitter
The splitter service chooses a variation for the current user. The available splitters are :
socloz_feature_flag.splitter.random(default) : chooses a random variationsocloz_feature_flag.splitter.shared_random: tries to use the same variation for feature having the same variation set (useful for Google Analytics)
A custom splitter can be written. It must implement Socloz\FeatureFlagBundle\ABTesting\Splitter\SplitterInterface.
Transaction service
Configuration : socloz_feature_flag.services.transaction
The transaction service counts successful transactions.
There is only one transaction implemented : socloz_feature_flag.transaction.session.
A custom transaction service can be written. It must implement Socloz\FeatureFlagBundle\ABTesting\Transaction\TransactionInterface.
State services
Configuration : socloz_feature_flag.services.state
The features states for the current user are stored/recalled from a list of state services. State is written to all services, and is read from the first one.
The default is : [socloz_feature_flag.state.request, socloz_feature_flag.state.session].
socloz_feature_flag.state.requestreads the query string and does not write anywhere,socloz_feature_flag.state.sessionreads/writes the session.
A custom state service can be written. It must implement Socloz\FeatureFlagBundle\State\StateInterface.
Storage service
Configuration : socloz_feature_flag.services.storage
The storage service stores global data (feature states, counts, ...)
The default is : socloz_feature_flag.storage.redis.
A custom storage service can be written. It must implement Socloz\FeatureFlagBundle\Storage\StorageInterface.
Analytics service
Configuration : socloz_feature_flag.services.analytics
The storage service generates the HTML code used to call the external analytics service.
The default is : socloz_feature_flag.analytics.google_analytics.
A custom analytics service can be written. It must implement Socloz\FeatureFlagBundle\Analytics\AnalyticsInterface.
License
This bundle is released under the MIT license (see LICENSE).
