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

  • Microservices allow for very agile projects because each small team (and their microservice) can be deployed independently
  • Use feature flags for all changes in order to increase stability
  • Feature flags allow for changing codepaths in production without redeploying to production
  • When using a feature flag consider creating a workflow that doesn't enable the code path for 100% of the users immediately. Instead enable it for 1%, then 5% after 30 minutes, then 10% after 1 hour and so on in order to reduce risk
  • No binary is perfect. By having this attitude an organization can release unfinished or incomplete features if the organization agrees it's ok to do so. With feature flags you can hide this unfinished feature until it's ready
  • Have hard deadlines for the release train and only rarely make exceptions
  • Have frequent releases for so that if an engineer misses a train they know they can easily catch the next one that's hours away (vs weekly or monthly releases)
  • When creating your CD environment and workflows design it so it so updates can be pushed frequently (hourly, daily). You don't have to push releases this often but you want the ability to do so
  • Keep your code modular in order to allow for dynamic deployments - deploying only what changed vs always re-deploying the entire binary / stack
  • Dynamic deployments also allow you to minimize data transfers, minimize storage space used, and only push features to users that needs them (language packs, binaries for a given processor architecture or platform, etc)
  • Dynamic deployments also allow for easy A/B testing



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