On Sat, 18 May 2013, Antonio Cavallo wrote:
I don't know any scenario like that: usually dependencies are frozen (and tested) separately in a "release". It makes the whole process simpler.
I guess you missed this part? [john wrote:]
(even though production is pinned to old releases, you probablywant to find out about the breakage early because it might get picked up later on in production)
Possibly they wanted to test how far they can push TDD, to be able to do testing on the entire code (apps + libraries) using the development branch (all commits done on it), api changes in the clients breaking the servers…
This is for integration testing, yes. I don't think TDD is relevant, because their system is useful regardless of whether you do TDD. The claimed innovation is not that they invented automated integration testing (!), but that they only rebuild modules where needed, so that faults are picked up sooner. I haven't seen open source code that makes it easy to do that, and I would likely use an open source project that did, because I have specific uses for it (which I briefly described in my post).
I hope you won't find *any* CI doing that: that'd be very "code specific" nothing that a CI should be aware of :D
Sorry, I probably don't understand this. Do you mean that CI should not be used for integration testing (and perhaps also that it shouldn't be used for testing deployment processes)? Why is that? I've found it useful for both of those things. Deployment is something that can go wrong, so it is useful to test it -- especially when it gets complicated. I have even seen CI used for testing upgrade of specific databases and associated configuration code, and that was also useful.
John
_______________________________________________ python-uk mailing list python-uk@python.org http://mail.python.org/mailman/listinfo/python-uk
