Software Engineering at Google Chapter #24 - Continuous Delivery (3 of 3)

  • If comprehensive testing is infeasible (think Android devices) instead aim for representative testing (test more on Samsung devices than FooVendor devices)
  • Use staged or staggered rollouts to slowly increase the percentage of devices that use the new code instead of pushing to all devices at once
  • Staged or staggered deploys also allow one to quickly and easily ship fixes. Better to find and fix the bug on 5% of the devices than 100%
  • Modular design and staged / staggered deploys also allow for automated A/B testing where humans don't need to watch a dashboard during each deploy
  • Frequent releases allow for a minimal divergence from a known good deploy
  • Google maps applies the philosophy that new features are good but it's not worth holding up a release (that has bug fixes) for a new feature. The new feature can be rolled out during the next release train
  • A new feature should not supersede the user experience of an existing product
  • Products that release more frequently and in smaller batches have higher quality outcomes
  • Velocity is a team sport (modular architecture and CI)
  • Use feature flags to evaluate changes in isolation



Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.