Principle: Ship small, ship often

Large, infrequent releases are risky. They have more bugs, are harder to debug, and cause more anxiety. Big releases often get delayed further.

Deploy small changes frequently:

1. Size: Each deployment should be small enough to:

- Review in < 30 minutes
- Roll back in < 5 minutes
- Understand the blast radius
- Debug if something goes wrong

1. Frequency:

- Ideal: multiple times per day
- Good: daily
- Acceptable: weekly
- Bad: monthly or less

1. Risk reduction techniques:

- Feature flags: deploy code without releasing features
- Canary deploys: roll out to 1% of users first
- Blue-green: instant rollback capability
- Progressive rollout: 1% -> 10% -> 50% -> 100%

1. Prerequisites:

- Automated tests (catch regressions)
- CI/CD pipeline (remove human bottleneck)
- Monitoring and alerts (detect problems quickly)
- Easy rollback (fix problems quickly)

1. Cultural shifts:

- 'Deploy is a non-event' (boring = good)
- Broken trunk is everyone's problem
- Small PRs get reviewed faster

Math: 100 small deploys with 1% failure rate = 1 issue
1 large deploy with 30% failure rate = 1 big issue

Small changes have small blast radius. If something breaks, you know exactly what changed. Frequent practice makes deployment routine and safe.