starcoach-hackathon/zarinpal-analytics-deployment
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: approve platform operations specification

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-08-20 18:54:54 +03:30
parent ec7a7753f6
commit e93eca1384
4 changed files with 66 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/decisions/0002-manual-server-build-releases.md
View File

@@ -15,18 +15,19 @@ The platform still needs to answer which source is running and how to return to
Use manual Qlockify-style deployment on the production server.
For a normal release, a trusted deployment user:
For a normal release, the trusted `ubuntu` user:
1. verifies the exact deployment/backend/frontend repository paths, remotes, branches, and clean working trees;
2. fetches and fast-forwards each checkout to the latest `origin/main`;
3. records the exact three resulting Git commit hashes;
4. builds application images locally with Docker Compose;
5. runs the dedicated migration and health/smoke checks; and
6. records the release as active only after validation passes.
2. manually runs `git pull --ff-only origin main` in each checkout, entering the source-forge username/password interactively when prompted;
3. invokes the deployment command, which verifies that all three checkouts are clean, on `main`, and equal to `origin/main` without performing any Git pull;
4. records the exact three resulting Git commit hashes under the ignored `/home/ubuntu/zarinpal-analytics-deployment/releases/` directory;
5. builds application images locally with Docker Compose;
6. runs the dedicated migration and health/smoke checks; and
7. records the release as active only after validation passes.
Rollback selects the previous release record, checks out its three hashes, rebuilds locally, and repeats the checks. Database down-migration is never automatic; migrations follow expand/contract compatibility.
The deploy flow may adapt Qlockify's `deploy.sh`, but it must not unconditionally `git reset --hard`. A dirty or divergent checkout stops for operator resolution so user changes are not destroyed.
The deploy flow may adapt Qlockify's `deploy.sh`, but Git pulling is a separate operator prerequisite and the deployment command must not store source-forge credentials. It must not unconditionally `git reset --hard`. A dirty or divergent checkout stops for operator resolution so user changes are not destroyed.
There is no CI/CD workflow, Actions runner, automated cross-repository event, private image registry, or direct automated production mutation.