Extension:E3 Experiments/Deployment

Current status

 * dashboard working on test.w.o
 * can validate bucketing on test.w.o by looking at cookies
 * test treatment
 * pre-activation impressions
 * activation impressions

Schedules
General deployments in Software deployments page, current iteration MediaWiki 1.20/Roadmap

Upcoming dates

 * July 23 (Monday) biweekly code update on test.w.o
 * push actual event logging??


 * July 26 (Thurs) E3's deployment window
 * July 30 (Monday) code flows to en.w.o
 * July 30 (Monday) code flows to en.w.o

Cadence
Per mw:MediaWiki_1.20/Roadmap, every second Monday at 7am WMF cuts a new branch, bump wmfN, checks out the code, and rolls out to machines. This is on the WMF Engineering calendar

Since E3Experiments doesn't have a named deployment branch, now that it is deployed, cutting a new branch will automatically get the latest git master (as of Monday 7am)
 * So it shows up on test.wikipedia.org 11am-1pm Monday
 * if there's a problem
 * ask (from Sam) for a special checkout from master, review, and a syncfile
 * E3's own deployment access requires approval from CT
 * fix it in some other deployment window in Software_deployments
 * or put it right in the regular E3 deployment window on Thursday
 * Then a week later that same branch wmfN gets deployed to en.wikipedia.org
 * ToDo need to request a modification to wmf-config/InitialiseSettings.php so that wmgEnableE3Experiments is turned on for 'en' as well as 'test'.

Testing
See ../Testing

Deployment details
If changes outside/above the regular cadence above are required, someone follows How to deploy code

submodule deployment
in wmf/1.20wmfxx, all deployed extensions are checked out in it as submodules.

Update the extension,
 * check out E3Extension master
 * then commit it as a submodule of the core, see
 * go to parent, commit the change to as a submodule of the core
 * request review

details
syncfile uses dsh to ssh to multiple hosts and asks them to rsync. Eventual move to git deploy

scap does more...

Avoiding inconsistent state is a manual process, e.g. do an initial sync of the files then a second sync of the config changes that turn it on.

2012-07-26 deploy to en.wiki
Latest code with feedback area, now enabled on en.wiki but eligibility does not begin yet. Also click tracking on Community portal page for m:Research:Community portal redesign

2012-07-20: sync E3 Experiments master to test.wikipedia.org
Special deployment: fixes to dashboard, more logging in lib/pef0.js

2012-07-19: turn on E3 Experiments on test.wikipedia.org
Previously E3 experiments were loaded as part of LastModified extension.


 * So check out new LastModified extension without this; Roan followed "How to deploy code" step 1c
 * then install new E3Experiments. This is not actually hooked up on backend, people will use BrowserXxx to test it. Roan followed "How to deploy code" step 1d for a new extension

wmf-config's initialiseSettings.php only turned it on for "test".

So the E3Experiments code got pushed out everywhere, but initialiseSettings only turns it on on test.wikipedia.org. It's live on http://test.wikipedia.org ! See #Testing

ToDo It shows up in testwiki:Special:Version as "JavaScript-Driven MediaWiki Extension Skeleton" 

To enable it on more sites, that's a config change: request, approve, and once someone does a syncfile, the new file is evaluated.