3 ms·
> Too slow of a CI means that instead of submitting small, isolated commits people start aggregating many changes into a small number of mammoth commits because
by Kwpolska 4y ago
> Too slow of a CI means that instead of submitting small, isolated commits people start aggregating many changes into a small number of mammoth commits because it is the only way to get things done.
I don’t understand the point here.
1. `git commit` and `git push` are two separate steps, you can commit often, but you can push once every few hours, assuming your computer won’t catch fire in the meantime.
2. If your CI builds every single commit pushed to a branch (instead of just building at every push), that’s a very weird CI config.
3. Where is the slowdown? Is it because your commit is waiting in a queue behind other commits?
- kaoD 4y agoI think they mean isolated PRs. Been there, done that.
- roflyear 4y agoMeaning, PRs are generally bad to require to do a build?
- bobthepanda 4y agoIn my experience it is a good idea to try and keep code reviews and pull requests short and sweet. It’s much easier to review small concise code than mega commits, it’s much easier to catch mistakes in them, and being set up to iterate small changes quickly tends to result in faster velocity (as opposed to people trying to avoid reviewing the mammoth, scary block of code that might take a half hour of reading to just read it, rather than review it.)
- rroot 4y agoThe fundamental problem with slow CI is developer's own context switch. If CI notifies me an hour later that my changes fail CI, I have might have to abandon my flow, sort out the failure and commit/push again. Then get back into whatever I was doing. This can be very taxing for developer's time and mental well being.