Forwarding for those who care about Beta Cluster but aren't on engineering@
----- Forwarded message from Chad Horohoe <choro...@wikimedia.org> ----- > Date: Thu, 01 Mar 2018 20:19:32 +0000 > From: Chad Horohoe <choro...@wikimedia.org> > To: "Development and Operations engineers (WMF only)" > <engineer...@lists.wikimedia.org> > Subject: [Engineering] extension-list-labs is dead, long live extension-list! > > Hi, > > In case you don't regularly follow the ops/mediawiki-config repository, > I've been doing some work to how extensions are deployed in Beta. Starting > today[0], extension-list-labs and extension-list-wikitech are gone and > should not be brought back. > > When deploying an extension to beta, you'll want to include it in a way > that gets it ready for production (eg: include in CommonSettings, enable in > InitialiseSettings-labs.php, *explicitly disable* it in > InitialiseSettings.php for production). Relevant docs have been updated on > wikitech. There's a couple of motivations for this: > > 1) Remind everyone that beta is a gateway to prod. In the past we've had > extensions languish in beta and never make it to production. By explicitly > including it in a production-like manner, it keeps this testing mentality > fresh and protects against forever-deployed-but-never-promoted code. > 2) Keep the technical differences between beta & production to a minimum. > This increases the reliability of testing in beta so we're more sure that > things are acting in a similar manner. > 3) Remind everyone that code needs appropriate review (security, > performance, DBA, etc) before going to beta. This has always been policy, > but it sometimes comes up as a question. This makes process self > documenting. > 4) Reduce race conditions when deploying to production. Deploying to > production will become a one-line change that can be safely deployed > without worry. Right now moving the config and inclusion pieces requires > either two commits or a specific order of operations in sync'ing it live. > Both are error prone. > 5) Eventually get rid of extension-list too. Ideally we want to swap the > l10n rebuild stuff to use its `--extension-dir` so we can just copy the > code in and get picked up automatically. Yay less maintenance. > > (spoiler: #5 was the reason I embarked on this adventure). > > So yeah: not a huge change. Yes the l10n for production will include a few > extension that we won't want...but those should be minimal compared to what > we already build and deploy (also: see #1 above). > > If you have any questions, feel free to ping me or anyone else in RelEng on > IRC. > > Happy scapping, > > -Chad > > [0] https://gerrit.wikimedia.org/r/c/415620/ > _______________________________________________ > Engineering mailing list > engineer...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering ----- End forwarded message ----- -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | Release Team Manager A18D 1138 8E47 FAC8 1C7D | _______________________________________________ QA mailing list QA@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/qa
