Deploy in one run, with nothing older to preserve
There is no previous system kept serving, so the playbook no longer knows about one: the retire flags, the temporary web address, the task that removed the old nginx snippet and the task that stopped the old container are gone. One run starts the container and points the Site's web address at it, and deploying an earlier tag is the rollback. The vars lose vhost, retire_nginx_snippet, retire_nginx_container and legacy_container; the Caddy role keeps only the snippet upsert. The deployment readme drops its staged-rollout sections and the glossary of words that no longer exist, and the plan's sequence and the operating notes describe the single run instead.
This commit is contained in:
1 parent
041b8b62fe
commit
f2d8058456
8 files changed
+152
-131
No files matched your search
+12
-10
@@ -123,16 +123,18 @@ The look is the Atelier Dining & Hospitality system from Stitch (`docs/design/st
|
||||
|
||||
## Sequence
|
||||
|
||||
1. Commit `nginx-menu/` to git so the current state is reproducible and revertible; create the `menu-admin` repo and move `CONTEXT.md`, `docs/`, and the ADRs into it.
|
||||
2. Storage layer: config, manifest read/write, atomic writes, boot validation, tests.
|
||||
3. Image pipeline: sharp variants, content-hashed filenames, tests.
|
||||
4. Public renderer: landing, Section and archive routes, design tokens and CSS.
|
||||
5. Admin: login, upload with browser pre-shrink, ordering, preview, publish/restore/delete.
|
||||
6. Container, compose dev fixtures, Ansible role, deploy to `menu-new.hopsngrains.com`, verify from a phone on restaurant wifi.
|
||||
7. Cutover: re-upload the current Food, Bar and Delivery menus, create What's On from the posters, switch `menu.hopsngrains.com` to the app, stop the old nginx container.
|
||||
8. After a week: remove the old container and `/var/lib/menu.hopsngrains.com`, delete the dated folders, drop the dead `Caddyfile`, and reduce this folder to dev fixtures.
|
||||
|
||||
Deleting the old 319MB directory is the only irreversible step, so it is last.
|
||||
1. Storage layer: config, manifest read/write, atomic writes, boot validation, tests.
|
||||
2. Image pipeline: sharp variants, content-hashed filenames, tests.
|
||||
3. Public renderer: landing, Section and archive routes, design tokens and CSS.
|
||||
4. Admin: login, upload with browser pre-shrink, ordering, preview, publish/restore/delete.
|
||||
5. Container, compose dev fixtures, Ansible role.
|
||||
6. Deploy: `make build-production TAG=<tag>` builds a multi-arch podman manifest and
|
||||
pushes it; the playbook in `ansible/` runs one Site to completion — it starts the
|
||||
container and points the Site's web address at it. There is no older system kept
|
||||
serving and nothing to retire, so there is no staged rollout; deploying an earlier
|
||||
tag is the rollback.
|
||||
7. Create the admin password once per Site (`scripts/provision-site-env.sh`), then
|
||||
`npm run check-site` and a phone.
|
||||
|
||||
## Out of scope
|
||||
|
||||
|
||||
Reference in new issue
Block a user