Software Engineering at Google Chapter #22 - Large Scale Changes (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
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"
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
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
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