On Sat, Apr 2, 2011 at 1:41 PM, Niclas Hedhman <[email protected]> wrote:
> On Sat, Apr 2, 2011 at 7:03 PM, Hans Dockter > <[email protected]> wrote: > > > I don't think so. With such a 'large' build structure you can figure out > > with the pre-commit build if you have broken something in projects that > > depend on your teams project. Google for example pushes this to the > extreme > > by having only one source root. > > Ok, so we have 3000 developers making let's say 10,000 commits per day > in total. Having 10,000 full builds won't work (well, maybe Google can > spare that much machines, but if we (investment bank) can't, I doubt > few others can), and having a few builds with all those commits would > also mean that my work won't committed because one of my upstream > dependencies didn't compile. This is a complex issue. But basically the opposite is the case. Having decoupled builds means that you are committing without having a chance to learn whether you have broken something in a project that depends on your project but is part of another build. I guess CI will tell (e.g. via snapshot jars). But then you have already broken another build and CI. Of course if you have teams that don't care whether they break something, you don't want to have a source dependency on their stuff. Not necessarily the people I want to work with but sometimes that is the way it is. In that case you can shield by not depending on their source nor depending on snapshots. You probably want to depend on specific versions. So the way how you want to partition your build depends a lot on the specifics of the organization. But the earliest feedback on whether you have broken something is when you have source dependencies. As you pointed out, for building a large source tree you need some computing power which is not provided by a desktop. But I'm very confident that often the hardware costs are much lower compared to the price of the late feedback and continuously breaking CI. I could provide you with some interesting examples if you are interested. You need in any case a smart tool which is capable of efficiently making use of this hardware ressources :). We are working on such a problem right now for a a product which is developed by 200 devs spread over multiple teams. > Sorry, I can't see the benefit. Total > blocking of commit progress (oh, maybe that is why it can work, each > person only commit once a month, but that kills team work then)... I > don't buy it. > As said, I think the opposite is the case. Commit is killed by not having pre-commit builds with good early feedback. But the good thing with Gradle ... Even if the Gradle devs have different opinions, Gradle always tries to be the _users_ humble servant and you can use it the way you want :). Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/24svnvk > I relax here; http://tinyurl.com/2cgsug > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
