On 10/20/05, Evan Levy <[EMAIL PROTECTED]> wrote: > This is what we do. Developers develop with Visual Studio, and the > build automation happens with Nant on the server pulling code from > source control. In fact, our developers don't really need to build > locally at all (but they do anyway). They can launch a server-side Nant > build from a custom web page (you could also accomplish this with > CC.Net). > > I can't see why you would need your developers to have Nant locally. > This would require synchronizing the local and server Nant scripts. The > only caveat to this situation is that any special steps needed to > produce you build output locally would need to replicated in Nant > scripts. Thankfully, that is exactly what Nant is good at, and you can > make your server build far more powerful, integrating lots of disparate > elements (like documentation, unit testing and distribution packages) > that you could easily do locally. > > e
Regarding developers building locally, I don't think I agree with the (implied) attitude mentioned above... if developers don't need to build locally, then you are placing them in the role of code generators, and the build server is then taking the role of quality and correctness auditor. I find that developer attitudes and quality improve when they are given the role of quality auditors as well as code generators. Humans, in general, are better measurers of quality than computers are, and simple things like mandatory code reviews, and encouraged full-build-and-test before checkin I have found to dramatically improve code quality. The knock-on effects to reduced number of bugs, improved developer morale and improved customer confidence (you may be your own customer here) have always more than paid for the cost of the developers' time to perform these checks. Regarding keeping the server and developer scripts in synch, your scripts are as much source code responsible for building the system as any other files, and should be checked in with the source tree they are building! To simplify the synchronisation, and setup and upgrade of developer machines, you could (as has been suggested in other posts to this list) check the NAnt runtime itself into the source tree, say under tools/nant. That way, if you have multiple projects being built separately, upgrading the version of Nant for one project doesn't break the build for the other projects just because their build scripts haven't been updated yet. Your CM updates NAnt locally and checks that the build still works, then checks in the new version of NAnt and updated build scripts... and magically, transparently and simultaneously all of your developers AND your build server are correctly using the new version of NAnt! Final comment, if all of your developers are using the build script, at least to verify changes before checking them in, rather than just a single build server, any bugs or inconsistencies in the script are much more likely to be found earlier (due to a much larger pool of testers), allowing more time to resolve the issues before the critical release phase. -- Troy ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
