Software deployment approaches

There are many approaches to deploying software, and this page describes some models used in the Wikimedia Foundation's environment.

Designing new functionalities

A/B testing

A/B testing usually results in a product being deployed default-on for half of the users at a given site. This is used to understand if the new features have the intended impact.

Releasing new functionalities

	User script	Gadget	Extension	Beta Feature
Desc				Makes a product available to registered users. It is a way for anyone interested to test the new feature and give feedback.
Pros	Any authenticated user can create Allows technical contributors to customize their own experiences on the platforms	Only admins and above user groups can enable a gadget Gadget can only ever be deployed at the wiki project level Can be enabled inside of preferences Can be deployed as an opt-out – driving adoption for the functionality	Creates consistency across Wikimedia projects Unclear how to test the functionality before enabling the functionality as a de-facto for everyone Properly maintained	By nature, calling a feature a Beta Feature, communicates that it is a work in progress Allows teams to gather feedback and improve before deploying
Cons	Maintenance cost since the user scripts and gadgets are always local Creates inconsistencies and tech debt if multiple projects use different code
	Requires that other users have technical understanding of the user script to be able to port in functionality No standard way to document - relies on word of mouth for people to hear about functionality	Adds product debt if deployed as a preference when it should have graduated as functionality for all Adds confusion to an already complex preferences ecosystem	Only developers with +2 rights can engineer this type of functionality Higher maintenance costs	Hard to drive awareness of the functionality* Cannot be deployed as an opt-out, people have to opt in Some beta features conflict in functionality with one another Only WMF product teams can develop Beta Experiences Doesn't make sense in the case of features for readers

* Regardless of the method of releasing, it's possible to run CentralNotice banners encouraging users to opt in. These may use JS and API queries, and allow for an instant reload of the page with new functionality enabled.

Feature flag

Also known as "snippet deployment" or "shadow deployment".

New products and features can be deployed but hidden behind a feature flag. This means that only people with a special URL (or other access method) will be able to see the feature.

Deployment in phases

Sometimes called waves or phases, this approach usually involves choosing wikis for several groups, and deploying to each group in turn, until the software is available at all relevant wikis. Product Analytics/Comparison datasets may be useful in identifying similar wikis.

Groups of wikis include:

• Big, medium, and small wikis
• DEI criteria: established and developing communities, LTR and RTL, Wikipedias and non-Wikipedias
• Mobile-heavy and desktop-oriented wikis
• Wikis with many newcomers and wikis with fewer newcomers

Wikis that have agreed to be involved in early deployment phases early are sometimes called pilot wikis or partner wikis. Sometimes pilot wikis are chosen for diversity. For example, a pilot group might include a Latin script language, an Arabic script language, and an Asian script language, or it might include wikis of different sizes.

Alternatively, a product may be offered initially only to certain subsets of users. Groups of editors include:

• Registered editors (but not IP or temporary users)
• Editors with certain user rights or similar characteristics
• Randomized based on user account number (e.g., all user account numbers ending with a 1)

Phases can also be by alphabetical order of the wiki's ISO 639 code.

Sometimes though, whether for technical or non-technical reasons, software is deployed everywhere all at once.

Regular weekly updates

Bug fixes, minor feature enhancements, and other non-emergency small changes tend to "ride the deployment train". This means that they follow the process in wikitech:Deployments. The deployment train uses containerized continuous delivery, which is a model that is mostly automated. In most cases, this means that routine software patches approved before the cutoff time will be deployed to different groups of wikis on Tuesday, Wednesday, and Thursday.

Backport windows are used for urgent updates, and also for configuration changes.

Feature deployment and feature configuration

Deployment and configuration are two different concepts.

A feature can be deployed but not visible to users. In that case, a configuration change may be needed to make the software available for use. The configuration can be different for each wiki.

Certain features (Growth features mainly) can be locally configurable by communities.