Hacker News Reader

Comment by gcb0 | Hacker News Reader

Which does nothing to improve the core problems with your workflow :)

Offloading tests to 3rd party will not help you ensure that tests run fast as they should.

Working too long on your branch will only make mergers more painful later.

We use svn and git, but the workflow is still local fast tests before even branches commits. No personal branches, only features, and update those often because they're not exclusively your silo. And commit/merge to head often. And head is the only place where you get the 2h integration test run. Because otherwise, you'd wait 2h after every branch commit (which we know nobody can do)

View on HN

> Which does nothing to improve the core problems with your workflow :)

Not sure what you mean. I state above how it helps my workflow.

> Offloading tests to 3rd party will not help you ensure that tests run fast as they should.

That's not the main point of CI. The main point is both: as a sanity check for tests pushed to the remote and also to not waste your time and CPUs running tests locally.

> Working too long on your branch will only make mergers more painful later.

I easily rebase off of master on a daily basis with git, no issues there.

rebase is not the same as avoiding merge problems.

what does it help you if you and other dev have their, often rebased or not, branches for a long time? the first one will be fine, second will have merge hell.

honestly, you are only comfortable with that setup because you probably work alone on a small team.

edit: and dont get me wrong, if that is the case, you are using the right tool for the job. i would love to be able to not rely on regular atomic commits in my huge dysfunctional group.

(Not the OP, obviously.)

> rebase is not the same as avoiding merge problems.

Yes it is. The point is this: Everybody rebases against "what is to become our next release" on a continual (daily if not more frequent) basis. If you have acceptable levels of unit testing and integration testing on your feature branches there's usually no problem with early (that is, way before the sprint ends) merging of feature branches to master. If your team is really paranoid and all your team's feature branches tend to pile up until the last day of the sprint[1], you could forcibly (via process) stagger your feature merges so that they're always at least 1 day apart to catch any bad interactions between features.

[1] This is indicative of other problems to do with process/management, so take the next bit of advice with a grain of salt.

Reply on news.ycombinator.com