This is a really great addition to this thread, thanks Christian, you've really brought this into clear focus for me!
When you talk about separate targets in this context, do you put targets into separate build files for each type of build, or do you use branching and manage all the build types in one large build file? There might also be another build that runs Fitnesse type integration tests after an install on a clean machine... I think this kind of test is probably more time consuming than what you get out of unit tests, which are really helpful for the private developer build. Doing the Private build in the IDE and referring to it with the <solution> task in the other types of builds seems a reasonable approach. I would suppose that if you are developing a single unit, that the developer might have a project that would not be part of the main build processes. -Kelly > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Crowhurst,Christian > Sent: Thursday, October 20, 2005 2:18 AM > To: nant-users@lists.sourceforge.net > Subject: [Nant-users] Developers using NAnt Directly > > I think Troy has summed things up nicely. A small point to > add to this discussion that I think is being implied by a > number of posts: the build comes in a number of flavours. > There's a Private build an Integration build and a Release > build (and possibly other variants). Each build is a superset > of the previous. For example, the Private build contains the > core set of tasks such as Compile (optionally Clean), > UnitTest, CreateDistribution (possibly). The Integration > build adds to the tasks that the Private build performs eg > Analyse, Document (possibly), and so on and so forth. > > I think its good practice to try and separate out each task > into a distinct target and then have higher level targets > that pull together these individual targets that correspond > to a Private build, Integration build and Release build. A > developer can then execute the PrivateBuild target before > check-in to increase the quality of the active codeline (aka > trunk) without burning time waiting on a whole set of other > tasks that are only really relevant for other build types. > > Christian E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized. ------------------------------------------------------- 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
