Re:Keeping master green at scale
by Cthulhu_ on Friday April 19, 2019 @10:20AM
(#19699817)
And at least in my limited experience, the impact of master being broken is pretty big, and even bigger when you have multiple teams. Either you block master - leading to a lot less than those 1000 commits making it to master on that day - or continue merging in stuff, which causes the root cause of the master branch to become fuzzy - and if your reporting is not in order, that is, if the person who broke the build isn't told they did, it'll be a lot of "Who broke master?" and people looking at each other to find out who is going to look into it. That's not scalable.
[ Parent
| on HN ]
Re:Keeping master green at scale
by erik_seaberg on Friday April 19, 2019 @01:45PM
(#19701453)
That's why master shouldn't be whatever you're about to deploy for the first time, but the known-good version that has been burned-in on prod (for an hour or a week or whatever), so if you have to abandon a release you don't have an entire team who already rebased on top of it.