4 ms·
> It definitely is. So are you saying I just imagined using this for non-web projects? > He's saying that "we uncover more problems sooner" which can only be
by JimDabell 1y ago
> It definitely is.
So are you saying I just imagined using this for non-web projects?
> He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast.
I don’t understand why you think this. Uncovering problems quickly is one of the major points of continuous integration and it’s in no way limited to the web.
> Where I work we can have weeks of testing to make sure that every feature has not introduced a bug.
This does not mean that branchless TBD is limited to the web, it means that it’s not suitable for your project.
- Disposal8433 1y agoYou misunderstood everything to the point I think you're doing it on purpose. I like TBD, but the article is NOT about TBD. > are you saying I just imagined I use TBD for everything and I like it. I was talking about the writer of the article, not you. The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. His other articles confirm this.
- JimDabell 1y agoYou said it was limited to web projects, I said I had used it in non-web projects and it wasn’t limited to web projects, and you said “it definitely is”. How else am I meant to interpret that? You are directly saying that what I have personally experienced isn’t possible. > The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. This does not resemble the article we are commenting on.