When we stop treating Parsoid/PHP as an extension, we need a deployment strategy that transitions over requests across the deployment boundary without breaking anything. We also need this to work with any necessary reverts.
The Plan
TL;DR: all machines (in main and parsoid cluster) are identical. Parsoid is loaded out of the regular hetdeploy ‘vendor’ branch. Startup configuration means the "parsoid cluster" machines have some extra config to expose the REST routes. Every deploy (of both Parsoid and the train) touches all machines in both main and parsoid cluster, so we’re always in sync.
- Parsing team code lands in parsoid.git master branch, as usual.
- Prior to deploy, parsing team manually updates /srv/parsoid-testing on scandium w/ the version of parsoid they hope to deploy (update_parsoid.sh) and triggers tests (see round-trip testing instructions). The mediawiki-config file CommonSettings.php has a special case for scandium which makes it load Parsoid from /srv/parsoid-testing and not the usual vendor repository.
- If the scandium test results look good, we tag that version in the parsoid repo as 0.12.0-a<N> and push the tag (git tag 0.12.0-a<N>; git push origin 0.12.0-a<N>)
- Checkout mediawiki/vendor.git *master* branch.
- update composer.json to reference parsoid 0.12.0-a<N>,
- do composer update --no-dev (which should only update parsoid)
- git add wikimedia/parsoid composer.lock composer.json <etc>; git commit -m "Upgrade parsoid to 0.12.0-a<N>" ; git review
- Review & merge. Will go live on beta cluster right away.
- The next time the train runs, it will take the master of vendor.git, including any new version of Parsoid, and deploy it to production, intially only to testwikis, then to group0, then more.
- Review impact.
- If all is well, hurrah.
- if things go bad, the train is pulled back, and if necessary the new version of Parsoid is reverted from, or a new fixed release is pushed in vendor.git and cherry-picked to production.