From e0668ef099ef238a83798038dc008cd2619b03ae Mon Sep 17 00:00:00 2001 From: lgelauff <32471480+lgelauff@users.noreply.github.com> Date: Sat, 10 Oct 2026 16:50:41 +0000 Subject: [PATCH] docs(deployment): deploy discipline; montage-dev's shuffled production copy Writes down the deploy discipline to work towards push-to-deploy: montage-dev deploys any branch under test, montage-beta deploys master after every merge, production deploys a release tag (vYYYY.MM.DD) on a commit that ran on beta; rollback is the previous tag. The old montage-dev / montage-beta / montage-prod branches were never used for deploys and still query the old database hosts: they are to be archived as tags. Step 4 shows the ref per tool. Documents montage-dev's database: since 2026-10-05 a shuffled copy of production (#652): what was cut, shuffled and reset, what is still real (usernames, coordinators' free text), who may use it and what not to do with it, and the rollback database kept until about 2026-10-19. Co-Authored-By: Claude Opus 5.5 --- deployment.md | 88 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 79 insertions(+), 9 deletions(-) diff --git a/deployment.md b/deployment.md index f597e7f9..5dd27067 100644 --- a/deployment.md +++ b/deployment.md @@ -193,10 +193,17 @@ git -C ~/www/python/src pull --ff-only #### 4. Run the deploy script +Which ref to deploy depends on the tool (see [Multi-environment setup](#multi-environment-setup)): + ```bash -bash ~/www/python/src/tools/deploy.sh --ref +bash ~/www/python/src/tools/deploy.sh --ref master # montage-beta +bash ~/www/python/src/tools/deploy.sh --ref # montage (production) +bash ~/www/python/src/tools/deploy.sh --ref # montage-dev: any branch under test ``` +Check the prompt (`tools.montage-beta@...` or `tools.montage@...`) before you run it: the ref +decides what goes live, and production must only get a release tag. + The script will: pull the latest version of itself, start the build, wait for completion, verify the SHA and port, warn if the running image already matches, restart the service, and smoke-test `/meta/`. @@ -353,15 +360,78 @@ toolforge webservice buildservice restart --mount all ## Multi-environment setup -Each tool account (`montage-dev`, `montage-beta`, `montage`) builds from its own branch and -has its own `toolforge envvars` configuration. The build command is the only thing that -differs: +Each tool account has its own `toolforge envvars` configuration and deploys from a different +kind of ref: + +| Account | Deploys from | When | URL | +|---------|--------------|------|-----| +| `montage-dev` | any branch (a feature branch or PR under test) | by hand, for testing | https://montage-dev.toolforge.org | +| `montage-beta` | `master` | after every merge into `master` | https://montage-beta.toolforge.org | +| `montage` | a release tag (`vYYYY.MM.DD`, e.g. `v2026.10.10`; `.2` for a second release that day) | by hand, as a deliberate promotion | https://montage.toolforge.org | + +#### montage-dev's database: a shuffled copy of production + +Since 2026-10-05, montage-dev runs on a copy of production's database (backup of 2026-10-04), +`s53126__montage_devcopy_20261004`, so that imports, migrations and slow queries can be tried at +production scale (#652). The copy keeps production's schema, collation (`utf8mb4_unicode_ci`) +and indexes (no index on `entries.name`, as on production, #650). + +What was changed in the copy (details and checks in #652): + +- **Recent campaigns are cut:** a campaign with activity in the last 12 months keeps only its first + round, and only if that round was imported from a category; other first rounds and all later + rounds are left out, so nothing shows which files advanced before results are announced. + Older campaigns are kept whole. +- **Jury data is shuffled:** vote values (with their reviews) are shuffled within each round, + ranking ballots within each juror; reviews are replaced by random characters of the same length; + favorites are reassigned; the `flags` table is emptied; results summaries are randomised and + made private. +- **Rights are reset:** campaign names get the prefix "[DEV COPY - shuffled]", production's + coordinators and organizers are removed, and montage-dev's own users and organizers are merged in. + A maintainer adds coordinators to the copied campaigns needed for a test. + +**Still real in the copy:** usernames (who was on which jury), coordinators' free text (audit +messages, disqualification reasons), timestamps, and uploader data in `entries`. So the copy is +for people who already have the same access on production, like montage-dev's maintainers: + +- Never set a fixed `userid` or the `devtest` environment on montage-dev: both log every request in + as a fixed user, which would be a real production user. +- Do not copy, export or publish data from it, and do not make another copy without the shuffle + (the procedure and its checks are in #652; its script is not in this repository yet). + +**Rollback:** the previous test database, `s53126__montage_dev`, is kept for two weeks after the +switch (until about 2026-10-19). Pointing `MONTAGE_DB_URL` back at it and restarting returns +montage-dev to its old test data. After that it is dropped, and going back means a new copy. + +#### Rules + +1. **Changes reach `master` only through a pull request.** Nobody commits or force-pushes to + `master` directly. +2. **Production only gets what montage-beta has run.** A release tag points to a commit on + `master` that has been deployed to montage-beta and checked there. +3. **There are no environment branches.** The old `montage-dev`, `montage-beta` and + `montage-prod` branches were not used for deploys and still query the old database hosts; + they are kept as `archive/-` tags only. Deploy a ref from the table above, + never one of those. +4. **Rolling back production** is a deploy of the previous release tag. + +#### Releasing to production + +After the commit has run on montage-beta, tag it (on your own machine, not on the bastion): + +```bash +git fetch origin +git tag -a v2026.10.10 -m "Release 2026-10-10: " +git push origin v2026.10.10 +``` + +Then follow [Deploying new changes](#deploying-new-changes) as `montage`, with +`--ref v2026.10.10`. The deploy script's `RESULT_SHA` must equal the tagged commit. + +#### Towards push-to-deploy -| Account | Branch | URL | -|---------|--------|-----| -| `montage-dev` | `master` (or feature branch for testing) | https://montage-dev.toolforge.org | -| `montage-beta` | `master` | https://montage-beta.toolforge.org | -| `montage` | release tag | https://montage.toolforge.org | +These rules are what an automatic deploy will follow: a merge into `master` deploys montage-beta, +a new release tag deploys production. Until that is set up, the same deploys are run by hand. ---