Tech:Deployment Policy

Deployments happen regularly and we deploy MediaWiki updates on a weekly cadence.

When reviewing a change to deploy, you must be sure if what it requires, this may include:
 * maintenance scripts
 * deployment parameters
 * testing

You can find this information by using what's available to you. You might want to consider the tags on PRs for updates.
 * A build tag means it should not affect production.
 * An i18n tag indicates you must add --l10n when deploying it.
 * The schema change tag indicates SQL files have changed and should be applied.
 * There is a ready to deploy tag to show someone is happy with it.

When merging updates, you should not rush. The following is a recommended order: You should also consider how many you can safely test at once.
 * Security updates
 * build only changes
 * i18n only or i18n with build
 * code changes without schema
 * SQL changes

You must use the beta environment to deploy to first unless you are sure that the changes will not cause issues.

The final say with any deployment rests with the deployer. It is perfectly acceptable to say you are uncomfortable deploying a change.

Gomerge
GoMerge can be used to merge pull requests in batch. Please see it's read me for how to install.

gomerge list --merge-method squash -r miraheze/mediawiki -t should be used to merge PRs.

Press space to (un)select and enter to run.