Just Ask
Ask me anything about software architecture, careers, PHP, Go and the craft of building software; I answer here, in the open, for everyone. (Page 2/6)
Whatever's on your mind, don't hold back. Questions reach me directly; I answer the good ones and publish them on this page. Your email is never published.
Gitflow's long-lived branches drift; that's why merges hurt. Trunk-Based merges small changes to main continuously, but it only works if unfinished features can't reach users — that's exactly what feature flags are for. You decouple deploy from release.
A persistent runner with root and the Docker socket is a server takeover waiting to happen. Two principles: ephemerality (each job runs in a fresh, throwaway environment that's destroyed) and isolation (no real Docker socket/root, unprivileged container/VM). Don't run fork PRs.
This is exactly GoReleaser's job. A GitHub Actions workflow triggered on tag push cross-compiles, publishes the GitHub Release, and auto-updates your Homebrew tap formula via the `brews:` block. Users then `brew install`.
Nightly dumps mean an 18-hour RPO — unacceptable in production. PITR closes the gap: take a periodic base backup, continuously archive the WAL to S3, and on recovery restore the base and replay WAL up to `recovery_target_time` 3 seconds before the bad `DELETE`. Use pgBackRest/WAL-G and rehearse the restore.
The problem is coupling schema changes to the deploy while old code is still live. Fix: backward-compatible (expand/contract) migrations decoupled from app deploy; add the column nullable, backfill in a separate throttled step, drop the old in a later release.
Eliminate the long-lived AWS keys in GitHub Secrets. With OIDC, make GitHub Actions an identity provider in AWS IAM; create a role whose trust policy is scoped to your repo/branch; the workflow gets short-lived STS credentials at runtime — no secret stored anywhere.
A 1.2GB image ships your whole build toolchain to production — slow and a big attack surface. Multi-stage builds fix both: for Go, the final stage can be `scratch`/distroless (a few MB); for PHP, target `fpm-alpine` + `vendor/`. Run as non-root.
Local state + 3 people = corruption and races. Move state to a remote backend: S3 (versioned, encrypted) for the state file, DynamoDB for state locking. A lock is taken before any apply, so a second apply waits. Per-environment state and applies from CI.
The symlink flip is atomic but not enough; OPcache keys on file path and the `current` path never changes, so workers keep serving old bytecode. Fix: flip the symlink, then gracefully reload PHP-FPM (not restart), and `opcache_reset` if needed. With Octane, code lives in memory so `octane:reload` is mandatory.
100M rows/day in plain MySQL fails: the B-tree index and full-table aggregates don't fit in RAM. If you think in SQL and need aggregation, TimescaleDB (hypertables + continuous aggregates + compression) is the low-friction win. InfluxDB only if you want a separate metrics stack.