The easiest deployment procedure is probably the sql.php method from tin, documented here:
https://wikitech.wikimedia.org/wiki/How_to_do_a_schema_change#sql.php
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T105109 Create UI for limiting banner impressions (banner diet?) | |||
| Resolved | awight | T86100 Do banner hiding with mixins | |||
| Resolved | awight | T45250 Redo /beacon/impression system (formerly Special:RecordImpression) to remove extra round trips on all FR impressions (title was: S:RI should pyroperish) | |||
| Declined | None | T90917 Get banner count via Special:BannerLoader | |||
| Resolved | • atgo | T78089 [epic] Banner History MVP | |||
| Resolved | • AndyRussG | T90918 Banner history mixins and data | |||
| Resolved | • AndyRussG | T94763 CentralNotice: key-value storage for new campaign-associated mixins/banner history | |||
| Resolved | None | T104508 Deploy CentralNotice schema change | |||
| Resolved | awight | T110963 Create CentralNotice campaign mixin tables |
Event Timeline
Comment Actions
Removing from the sprint, after discussion. This can happen much closer to the time we deploy the feature proper.
A slightly mutant BLOB version has been deployed to master hence betawiki, note that the rest of the migration has to happen in a second patch now.
Comment Actions
It's deployed to the beta cluster, but not to production. It could be deployed to production (the BLOB issue mentioned above is OK, no need for a second patch), though I was thinking of waiting until we tested everything on the beta cluster... Just on the intuition of not wanting to send anything to production until the user-facing feature (in this case, banner history) has been seen working as promised on beta. It doesn't necessarily have to be that way, though....