peter/daybook
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add CHANGELOG; switch runbook rollback to tags

Browse source 
- CHANGELOG.md started (Keep a Changelog style), with the v0.1.0 release
  notes; versions track the git tags and __version__.
- Runbook §7 now deploys a specific tag (git fetch --tags && checkout
  vX.Y.Z) and rolls back to the previous tag, with a note that rollback
  reverts code not data (restore the data backup if a migration ran).

(The deploy kickoff brief lives in planning/, which is gitignored — it's a
local hand-to-the-agent note, not shipped in the repo.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
peter 2026-09-03 14:47:09 +01:00
parent 16737f3ff4
commit 6859be688e
2 changed files with 64 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

24
deploy/cloud_agent_deploy.md
View file

@ -202,25 +202,33 @@ Confirm the response includes `id`, `url`, and `api_url`, and that opening
## 7. Redeploy Loop (routine updates)
This is the command you run every time you're asked to ship a new version:
Releases are tagged `vX.Y.Z` (SemVer). Deploy a specific tag rather than a
moving branch, so what's live is always a known, named version — and note
the currently-deployed one before switching, for a clean rollback target:
```bash
cd /opt/daybook
PREV_SHA=$(git rev-parse HEAD)
git pull
PREV_TAG=$(git describe --tags --exact-match 2>/dev/null || git rev-parse HEAD) # what's live now
git fetch --tags
git checkout v0.1.0 # the tag you were told to deploy (latest: git tag -l | sort -V | tail -1)
docker compose -f deploy/docker-compose.yml up -d --build
```
Then repeat the verification in step 6 (capabilities check at minimum). If it
fails:
Then repeat the verification in step 6 (and confirm `/api/capabilities`
reports the `version` you expect). If it fails, roll back to the previous
version and report the failure (build log / migration error / failed health
check) rather than retrying blindly:
```bash
git checkout "$PREV_SHA"
git checkout "$PREV_TAG"
docker compose -f deploy/docker-compose.yml up -d --build
```
to roll back, then report the failure (build log / migration error / failed
health check) back to the operator rather than retrying blindly.
Caveat: rollback reverts code, not data — a release that already applied a
DB migration may not cleanly downgrade against the migrated `db.sqlite3`.
For a routine forward release that's fine; if a rollback is needed after a
migration, restore the pre-deploy `deploy/data` backup (see §9) alongside
the code checkout.
`deploy/.env` and the data directory (wherever `DAYBOOK_HOST_DATA_DIR` points,
or `deploy/data` by default) are untracked, so `git pull` never touches them —