> And what happens if you need to do a rollback of a component?
You revert the offending commit. That triggers an automatic deploy (or, even more likely, your buggy change gets caught in the canary stage and automatically reverted for you).
The Google philosophy is called "live at head" and it has a bunch of advantages, provided your engineers are disciplined enough to follow through.
Until you run into things like "your partners deploy once every two months" or "the team's deploy is delayed by X due to unforseen changes downstream" or ...
Protobuf is built specifically for Google and Google's way of doing things. Not everyone is built like Google.
Well, the core problem is that you shouldn't be deploying as infrequently as every 2 months...you should spend engineering energy to fix that rather than on working around it.
I worked at Google; I'm describing to you exactly how the infrastructure worked.
Yes, Google's internal infrastructure is that good. It's easy to get caught up in the "haha cancel products" meme and forget that this company does some serious engineering.
What Google does with its internal infrastructure is of limited applicability to the majority of people, where interface stability is the prime directive.
They are not. A good interface rarely ever needs to be changed; the point of live at head is that it's impossible to commit a breaking change as long as there's a test depending on the thing you broke.
You revert the offending commit. That triggers an automatic deploy (or, even more likely, your buggy change gets caught in the canary stage and automatically reverted for you).
The Google philosophy is called "live at head" and it has a bunch of advantages, provided your engineers are disciplined enough to follow through.