User:Jdlrobson/Feature management in MediaWiki (for developers)
Improvements to MediaWiki are merged directly to the master branch which is deployed (usually weekly) to Wikimedia servers the train. When building larger features this requires additional care to balance rapid development against not breaking existing experiences. The use of git feature branches is possible, but problematic given the Wikimedia ecosystem, where developers outside the team building a feature are often committing bug fixes and maintenance patches to existing code, increasing the likelihood of merge conflicts when merging code into master. As a result, developers often rely on configuration flags to control when we ship new features.
Currently, feature management in MediaWiki Core is relatively primitive and non-standardized across teams. This led to an RFC to standardize how we roll out features. The code has to handle its visibility state by using $config object and some additional checks that may have to be hardcoded in multiple places. It is not a problem when we want to handle only a single feature.
How teams are currently building features
[edit]In MediaWiki
[edit]Typically teams will use a primitive form of feature management that boils down to conditionally enabling a feature via a boolean.
$wgMinervaTalkAtTop = true;
It will be used in code like so:
$config = MediaWikiServices::getInstance()->getConfigFactory();
if ( $config->get('MinervaTalkAtTop') ) {
... // feature code goes here
}
Typically what happens is a configuration flag is used (usually a boolean) and new code is conditionally added.
An extension Extension:BetaFeatures expands this to provide a framework that allows logged in users to conditionally try new features before they are ready. Typically this requires a certain level of quality and set of expectations from the user's who use it.
Web team
[edit]The primitive form of feature management has proved insufficient to the web team, who often want to control the groups of users that they enable to (and sometimes rolling back / disabling) features. As the web team began to build desktop improvements, it created a variety of features, many of which had dependencies on one another.
Many of the feature flags allow for development of incomplete/broken features. For example, when the team begins building a feature, initially the feature flag will have no visible effecvt on the page.
Workflow
[edit]- Build feature flag and define dependencies e.g. the sticky header feature in the Vector 2022 skin requires the search feature built in Vue.js to function and requires the user is logged in.
- Create feature
- Roll out to beta cluster for wider testing with other teams
- Roll out to production
- Remove feature flagged code (Note: sometimes this code is unexpectedly retained as a user preference).
Examples
[edit]In mobile site
[edit]The web team has built two feature management systems. Initially, it was built to support development in the Minerva (the mobile site). Typically feature roll out involved deploying to an opt-in beta site (available to all users) and then deploying to all users. In some situations, features were restricted to logged in users, or were shipped to all logged in users before enabling to everyone. Given we do not cache the HTML in Varnish for users of the beta version of the site, and logged in users, this lowered the risk of deployments.
At its core this resulted in an array mapping defined states to a boolean. In the following case, a feature that positions the talk button at the top of the page is only shown to logged in users:
$services = MediaWikiServices::getInstance();
$featureManager = $services
->getService( 'MobileFrontend.FeaturesManager' );
$skinOptions = $services->getService( 'Minerva.SkinOptions'
if ( $featureManager->isFeatureAvailableForCurrentUser( 'MinervaTalkAtTop' ) ) {
... // do something.
}
Code utilizes this by the following method (base means anonymous page views - name is a historic artifact)
$wgMinervaTalkAtTop = [
"base" => false,
"beta" => false,
"loggedin" => true
];
This feature management was limited to use inside the mobile site and built inside Extension:MobileFrontend. Given the Minerva skin runs on the desktop site, one of the decisions we made here was that we'd use the feature management to enable features on mobile away from a set of defaults for the desktop site.
In desktop
[edit]The Desktop improvements project required working inside the Skin:Vector repository. The feature management system developed for use inside the mobile site could not be used. In this project, there was no concept of a beta site for anonymous users, but the same distinction of shipping features to logged in users or anonymous users applied. In addition to this, as the system evolved, it became clear that our QA engineers, product owner, designer and community collaborators needed a way to check in on upcoming features. To satisfy this we made it so that any feature could be turned on via a feature flag. For example the page tools feature could be turned on by appending ?vectorpagetools=1 to the end of any URL e.g. https://en.wikipedia.org/wiki/Desktop?vectorpagetools=1
Over time the feature management system has been used for user facing features as well as large scale technical changes - for example the effort to provide consistency between Vector 2022's icons and Codex.
Growth team
[edit]...(summary of how feature flags are used)...
Workflow
[edit]...(provide details of workflow from conception to deployment)...
Examples
[edit]...(provide examples of complex feature management-like systems your team uses)..
Editing team
[edit]...(summary of how feature flags are used)...
Workflow
[edit]...(provide details of workflow from conception to deployment)...
Examples
[edit]...(provide examples of complex feature management-like systems your team uses)..
DST team
[edit]...(summary of how feature flags are used)...
Workflow
[edit]...(provide details of workflow from conception to deployment)...
Examples
[edit]...(provide examples of complex feature management-like systems your team uses)..