Patch: Developers submit a patch, sometimes with dependencies, to Gerrit. The patches are currently based off of the master branch and are merged to the master branch after they've been reviewed
Master: What gets deployed to production
Beta cluster: A test wiki that syncs the master branches of many extensions approximately every ten minutes, which is available at http://en.m.wikipedia.beta.wmflabs.org. The Release Engineering team run browser tests against the beta cluster every night
Production: The WMF currently uses a one-week deploy cycle, in which the test wikis, including testwiki, are deployed to first, and all of Wikipedia is deployed to last. Wikipedia is considered production
Train: Used to refer to the latest deployment branch starting to roll out to the test wikis
SWAT: A deploy of one (typically) or more patches to production by a member of the SWAT group. SWAT deploys are scheduled in advance on the Deployments calendar
Feature: A piece of functionality provided by MobileFrontend or Gather
Prototype: A new feature or a dramatic change to an existing feature, which is shown to users before it is considered stable
Experiment: A process in which we make one or more changes to an existing feature, e.g. adding/removing UI components, and measure the effects of those changes with either validating or invalidating our stated hypotheses
Alpha/beta/stable: The three feature release channels provided by MobileFrontend, listed in order of increasing stability. The alpha and beta release channels are opt-in by default
The Product Owner (PO) and Designer design a feature/prototype/experiment and create an epic-sized task that describes the feature with enough detail that both the stakeholders and the engineers, represented by the Tech Lead, can understand the request. Sometimes the task is broken up into one or more subtasks by the PO and the Tech Lead so that the work can be estimated by the Tech Lead initially and then the team of engineers.
In most instances, a feature or experiment is released via the beta release channel first – with alpha reserved for prototypes – as there is no production-like environment to test/QA/sign off in, there's only the beta cluster.
Some time after the feature/prototype/experiment is deployed to production, the PO makes a decision to promote it to stable from beta.
There are a number of examples of community volunteers adding features to the mobile site by submitting patches directly, for which a task may or may not be created depending on the reviewer. Typically community patches are treated as outstanding code review and added directly to the Code Review (non-sprint) column on the Reading Web workboard.
Likewise, there are also some features that are added to the mobile site by the engineers. These features are often prototypes – although they're referred to as experiments – and are released using the alpha release channel.
If the feature is developed in beta or alpha, there are often fewer technical challenges: beta and alpha aren't cached but stable is. HTML is cached for up to 30 days but JavaScript and CSS loaded by the ResourceLoader isn't. So, if an engineer has to make a change to the HTML in stable, then they must include a JavaScript shim that handles cached HTML. This is particularly important when promoting a feature from beta to stable.
After the patches are reviewed and merged, the associated tasks are moved to sign off where either the Tech Lead or Product Owner signs them off on the beta cluster. Regardless of whether the work is signed off or not, the work will be deployed to production. If a patch is merged before Thursday, then it will ride the train the following week. Otherwise, there'll be a delay of a week. Therefore, the Tech Lead or Product Owner has anywhere between three and eight working days to sign off a feature.