|
|
|
|
|
|
by hzhhzh
2997 days ago
|
|
|
This approach is safer because you are getting some feedback sooner, from the CI running on your feature branch, but this branch is telling lies. It is not the real story. This is not a change set that will ever make it into production, it isn’t integrated with other branches yet. So even if all your tests pass on this branch, some may fail when you merge. It is slow because you are now building and running everything at least twice for a given commit. Copied from post. |
|
|
Let's consider it this way:
Common starting point A, current master, where everything passed already.
Two people are working on their own mostly independent features on branches: B1 and B2.
So who's the next master? Well it depends on which of the two finishes first. If B1 tests their branch and they are the first to merge, well there's no double work. They tested what would be the next master.
Say B2 finishes next. If they run their tests now, they have a good idea if their own changes are the problem or not. If they wait to rebase and then test, they now need to consider two causes: (1) their own changes and (2) the combination of B1 and B2 changes.
Sure for a small enough change and good enough set of test cases, the combination of B1 and B2 won't be hard to figure out. But then the situation already is the team knows how to build big features out of many small changes. I would say that's not the majority of the developers out there IME.
Slow regarding build and running really depends... We've gone over to more test oriented coding because the automated tests help us do better than manual testing. A collection of tests built up over time tracks the gotchas/corner cases/etc.
If the developer were better at catching bugs without these test cases, then we would still be doing it manually. But I would rather wait 3 hours for my automated tests than spent 3 hours double/triple checking my code.
The specifics do matter; for some code bases the approach in the article may be right. But building and running some thing twice may not be the wrong thing. I think there's a failure to realize there's an engineering and process design/compromise to be made...