5 ms·
In my experience the opposite is true - no one is doing CI. But that's only because the definition of CI is unrealistic/impossible for large teams, specifically
by dlor 6y ago
In my experience the opposite is true - no one is doing CI. But that's only because the definition of CI is unrealistic/impossible for large teams, specifically this requirement: https://en.wikipedia.org/wiki/Continuous_integration#Everyone_commits_to_the_baseline_every_day https://en.wikipedia.org/wiki/Continuous_integration#Everyon...
I've never seen a team that operates with every developer committing every day. Small commits merged into a stable trunk as often as possible, yes. But every developer merging code every single day is unrealistic, counter-productive, and incompatible with code review practices.
- deleted 6y ago[deleted]
- jdbernard 6y agoI'm actually having this discussion with a client at this very moment. Client is expecting that check-ins to baseline happens multiple times per day. On our distributed team with junior and senior people in different locations the ability to do async code reviews is critical to maintaining quality. Automated linting, unit testing, and other CD-friendly tools can't teach and enforce code quality the way we need with our junior developers.
- lhorie 6y ago> Everyone commits to the baseline every day That's not a hard requirement, it's more like a principle. In my experience, it's easier to review smaller things than gigantic PRs. I don't take this line item to mean literally committing every chronological day, but in the sense of not withdrawing from the world and building out entire systems in a cave, so to speak. It's a more granular version of "prefer agile over waterfall". Another subtle aspect of the commit-often mantra - particularly when it comes to a workflow with tests running in CI - is that you are encouraged to build software in a bottom up fashion (simply because if you try to "tack on" an incomplete feature to an existing live system, it'll obviously not work).