Deployments/Train vs backport

Deployments

Jump to current event

• Deployment calendar
  • Long-term calendar
  • 1.44 Roadmap
  • Train overview
  • Archive
• Blocking tasks (Current task)
• How to monitor errors
• Holding the train
• 🚨 Emergencies
• How to deploy code
  • Heterogeneous deployment
  • Train deploys
• Backport windows
  • How to deploy backports
• Backport vs Train vs Special Window
  • Train vs Backport
  • Special Windows
  • Backport windows
• Risky change notification

[]

There are types of changes that should be deployed via the train, types of changes that should be deployed via backport windows, and types of changes that should be deployed via dedicated deployment windows. This document is an attempt to codify the criteria used to determine the method by which a change should be deployed.

This change deployment criteria uses IETF RFC 2119 keywords.

Train

• New extensions MUST be deployed via the train (before they are enabled)
  • Justification: Localisation (l10n) is generated for the whole site not for only a single version. L10n logic currently expects new extensions to be deployed via the train (see: mw:Writing_an_extension_for_deployment#Preparing_for_deployment for more details)
• Changes to l10n SHOULD be deployed via the train
• Changes requiring library upgrades in mediawiki/vendor SHOULD be deployed via the train
• Changes requiring several commits across many branched repositories SHOULD be deployed via the train
• Any change to MediaWiki core, extensions, or skins MAY be deployed via the train
  • NOTE: For many types of changes it is often more appropriate to deploy these changes via backports and that SHOULD be the default choice.

Backports or Dedicated windows

• Changes to operations/mediawiki-config MUST be deployed via backport or a dedicated deployment window
• Changes meeting the criteria for dedicated windows MUST NOT be deployed via the train and SHOULD be deployed via dedicated windows
  • Justification: train conductors don't usually understand the aspect or subsystem being changed, and having people who do understand it in dedicated deployment windows means it's less likely to break things badly, and any breakages are more likely to be noticed as breakages.
• Risky changes SHOULD be deployed in dedicated windows but MAY ride the train provided that the developer comments on the train task
• Fixes for critical regressions SHOULD be deployed as soon as possible via a dedicated window or a backport window.
• Changes that are incompatible between wikiversions, such as changes to job serialization format SHOULD be deployed via dedicated windows rather than deployed via that train
• Non-trivial changes to CSS, JavaScript, PHP, or configuration of MediaWiki core, extensions, or skins that does not require PHP library upgrades SHOULD be deployed via backport or dedicated window
• Trivial changes to CSS, JavaScript, PHP, or configuration of MediaWiki core, extensions, or skins that does not require PHP library upgrades MAY be deployed in backport windows (provided the backport deployer is comfortable deploying the change)