How do I design a self-healing deploy that auto-rolls back when the error rate spikes?
Hold the new version at a canary weight and check 5xx and latency against a threshold; on breach, roll back to the last stable release and alert the team.
Tag
Continuous integration and delivery: the path from test to production, automated.
12 answered questions carry this tag.
Hold the new version at a canary weight and check 5xx and latency against a threshold; on breach, roll back to the last stable release and alert the team.
Make Canary the default for routine releases and save Blue-Green for big cutovers needing an instant flip, since both demand expand/contract migrations.
Drop the long-lived branches, merge small changes to main continuously, keep unfinished work behind a flag that's off in prod, and delete flags once done.
Move the runner to a register-run-once-destroy model and run jobs unprivileged; never hand over the Docker socket, and never run fork PRs on it.
Let one tag-triggered workflow cross-compile and publish the GitHub Release while the brews: block updates the tap formula; the tap needs its own PAT.
Add the column nullable, move the backfill to a separate throttled step, run migrations in their own stage, and drop the old column in a later release.
Delete the long-lived AWS keys from GitHub Secrets and assume a repo/branch-scoped IAM role over OIDC; pull non-cloud secrets from a manager at runtime.
Leave the build tools in the builder stage: make the final stage distroless/static or scratch for Go and fpm-alpine for PHP, and run as non-root.
Move state to a versioned, encrypted S3 backend and add a DynamoDB lock table (deprecated but working), keep state per environment, and apply only from CI.
After flipping the symlink, gracefully reload PHP-FPM rather than restarting it; on Octane, octane:reload is mandatory and opcache_reset is optional.