One loop for everything
Every deployable thing I run — client platforms and this site alike — ships through the same loop:
- Commit and push to my self-hosted Gitea
- Jenkins picks it up, cancelling any in-flight build first
- Images build, the cluster rolls the deployment
- A verify script hits the health endpoint and the key routes before I call it done
Push to live is about ten minutes. The version stamped on every deploy comes from a VERSION file in the repo, so any running container can tell you exactly which commit it is.
Why cancel-before-trigger
Most CI setups queue builds. For a continuously-deployed site, a queue is a lie: if I push three times in five minutes, only the last state matters — the middle builds would deploy already-stale code, in order, slowly. Cancelling the running build and starting fresh means the pipeline always converges on the newest commit and never spends ten minutes shipping something I already replaced.
Staging without a staging environment
For a one-person operation, a second cluster is cost without benefit. My staging is the production cluster reached through a hosts-file override — same images, same database engine, same TLS, reached at the real domain before DNS agrees. It removes the entire class of "worked in staging" surprises, because there is no separate staging to diverge.
Why bother, for a personal site
Because the alternative is a snowflake server. The pipeline gives me an audit trail of every change, rollback by re-deploying the previous tag, and the certainty that the machine serving you this page could be rebuilt from the repo this afternoon. Boring, reproducible delivery is a feature I sell — running my own site any other way would be strange.
Comments