Deployment Guidelines

Deployments must be predictable, reversible, and low-risk. A deployment is not just pushing code—it is altering a live system used by real people. Treat it with respect.

When NOT to Deploy

As a general rule, deployments should not be attempted:

• After 4pm on any day
• On a Friday
• Before or during bank holidays
• When the person deploying cannot remain available for at least one hour post-deployment

Exceptions may be made for critical issues where the cost of delay exceeds the risk of the deployment.

Live Data

Before automatically or manually changing live data:

• A suitable backup must be identified or created
• Recovery steps must be understood before changes begin
• Both files and databases are considered data and must be protected
• Never assume backups exist—verify them

If you cannot roll back, you cannot deploy.

Pre-Deployment Checklist

The person deploying must confirm:

• The work has passed QA and meets the Definition of Done
• The PR has been approved and merged into the correct branch
• Environment variables, secrets, and configuration values are correct
• All migrations have been reviewed and tested on a staging environment
• Feature flags (if used) are in the desired state
• No unplanned changes or pending commits remain

If any item is unclear, stop.

Migrations & Schema Changes

If the deployment includes database schema or data migrations:

• Ensure the migration is idempotent (safe to run more than once)
• Confirm the migration time will not exceed acceptable outage windows
• Validate foreign key relationships and indexing are correct
• Have a rollback or reversible strategy (down script, snapshot, or plan)

Data changes are the most dangerous changes.

Staging First

All deployments must go through staging unless:

• The fix is a trivial UI change, or
• A critical bug requires direct hotfixing

Staging verifies:

• Code runs in a production-like environment
• Configuration changes behave as expected
• Migrations do not destroy or corrupt data

If staging breaks, production will break louder.

Monitoring & Verification

After deployment:

• Check application logs for errors or warnings
• Verify key user flows (login, checkout, form submissions)
• Confirm integrations are communicating correctly (payments, search, ERP, etc.)
• Keep an eye on performance metrics where available

Deployment is not finished until the system is verified healthy.

Rollback Plan

Before deploying, know how to undo it:

• Backup restore instructions
• Database snapshot or rollback script
• Code revert process
• Who must be notified if rollback is required

If you couldn’t revert within 10 minutes, you didn’t plan well enough.

Communication

For deployments that affect users or client operations:

• Notify stakeholders if downtime or degraded performance is expected
• Confirm who is available if something goes wrong
• Document the deployment outcome and any anomalies

Silence creates panic; clarity creates trust.

Definition of a Safe Deployment

A deployment is considered safe when:

It can be completed without surprises, verified without uncertainty, and reversed without drama.

If any of those conditions fail, postpone the deployment.