[QA] Fwd: [Engineering] extension-list-labs is dead, long live extension-list!

[Greg Grossmeier]

Forwarding for those who care about Beta Cluster but aren't on
engineering@

----- Forwarded message from Chad Horohoe <chorohoe at wikimedia.org> -----

> Date: Thu, 01 Mar 2018 20:19:32 +0000
> From: Chad Horohoe <chorohoe at wikimedia.org>
> To: "Development and Operations engineers (WMF only)" <engineering at 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
> Engineering at 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 |