Ship small, isolated changes
"We deploy code in small increments to reduce risk and maintain speed."
Why this exists
Delayed shipping is its own operational failure. It lowers team momentum and generates large deployments that fail in production. We do not solve this by slowing down. We solve it by breaking changes into small, isolated pull requests that can be verified and deployed independently.
Operational Flow
Scope: Keep pull requests self-contained. If a change requires multiple separate branches to be safe, split the scope.
Feature flags: Put user-facing changes behind flags using LaunchDarkly or environment variables. Do not write custom flagging code.
Branches: Merge branches into main within two days. Open communication channels early for complex changes.
Reviews: Review pull requests within one business day. Ping reviewers on Slack to keep work moving.
Pipeline: Automate deployments to staging on every merge to main. Trigger production deployments manually.
Rollbacks: Verify the rollback path before deploying. Ensure schema changes have rollback scripts and flags have kill switches.
Post-deployment: Monitor dashboards and error rates for ten minutes immediately after deploying to production.
What good looks like
- A pull request changes 150 lines of code to implement a single database constraint.
- An engineer deploys a change at 4:00 PM on a Thursday, verifies the metrics at 4:10 PM, and leaves without issues.
- You enable a flag for 5% of traffic, verify that latency remains stable, and roll it out to 100% the next day.
What NOT to do
- Do not merge half-finished pull requests. Save additional improvements for subsequent branches.
- Do not deploy changes after 3:00 PM on a Friday unless you are applying an emergency hotfix.
- Do not skip monitoring after a deployment. That leads to after-hours alerts.
- Do not rely on the QA process to catch errors you did not test locally.
The most effective engineering teams maintain velocity by reducing change size rather than lowering standards. A 50-line pull request that adds a single database query takes ten minutes to review, five minutes to test, and thirty seconds to roll back. A 2,000-line change that refactors authentication while rewriting notification templates takes hours to review, introduces unforeseen side effects, and takes a weekend to debug. Keep pull requests small to ensure production remains stable.
Our requirements are clear. Know your rollback path before shipping, verify active metrics after deploying, and merge changes within two days. Feature flags separate deployment from release, allowing you to ship code without immediately exposing it to users. When you separate these tasks, velocity increases. The goal is to make deployments uneventful.