Software Engineering at Google Chapter #22 - Large Scale Changes (3 of 3)

  • The change creation phase...
    • This is the code change itself, not the creation of a "change control ticket" or "change request"
    • This can be a single large edit that is sharded into smaller independent changers
    • The change process should be automated as much as possible and from there the user will need to make smaller manual changes when necessary (undo the change temporarily for a small subset, manually clean up a merge conflict, etc)
    • If it's a small large change you can consider not automating it and "sharing across humans" instead
  • The shard management and change submission phase...
    • Google has a tool that automatically shards LSCs based on ownership rules and project boundaries
    • Each shard should go through it's own "test, mail, submit" process
    • Be sure to somehow rate limit the number of shards that are being processed at a given time
    • Also consider running sharded LSCs at a lower compute priority
  • Flakey tests can greatly impact the speed of a LSC because it's the owner of the LSC (not the owner of the test) that will need to deal with them
  • LSCs must pass project-specific pre-commit tests before being committed
  • After the tests are validated Google's automated system then parses the OWNERS file and e-mails them for approval
  • The LSC process ignores pre-submit failures that were happening before the LSC. It's up to project owners to fix these and/or give the go-ahead even with errors
  • Project owners are the ones who approve LSCs that apply to their code but Google also has "global approvers" that can approve in any project, hence speeding up the process
  • The cleanup phase...
    • There needs to be a definition of "done"
    • The definition may vary by LSC, but it's important that all work gets done and finished in order to keep the codebase consistent
    • Done!
  • LSCs allow for more possible changes after the code is written and thus some design decisions are not 100% set in stone
  • No matter the size of your organization you should think about how to make LSCs to your code for long-term maintainability
  • < BACK NEXT >



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