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. ---