>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? < Ok, not sure in what context you're using the term branching - I almost started rattling on about whether to branch your trunk / mainline to support a release! As to implementation of the NAnt script I think its a good idea to start trying to keep the individual targets in the same build file. For the next business project you should copy this build file "as is" make the changes required for the new project and then compare the two build files side by side (thank Marc Holmes and Mike Roberts for this advise!). At that point you should try and identify the common tasks / targets and pull these out into a common NAnt file that you "call" or "include" in the original build file. I hope I was on target with your question? I can strongly recommend the following resources that talk about the different types of build: http://www.cmcrossroads.com/articles/agileoct03.pdf http://www.cmcrossroads.com/articles/agilejul03.html I can strongly recommend the following resource that talk about how to structure your solution directory tree to facilitate the build: http://mikeroberts.thoughtworks.net/blog/archive/Tech/ArticlesandPapers/Howtosetupa.NETDevelopmentTree.html Christian -----Original Message----- From: Anderson, Kelly [mailto:[EMAIL PROTECTED] Sent: 20 October 2005 17:31 To: Crowhurst,Christian; nant-users@lists.sourceforge.net Subject: RE: [Nant-users] Developers using NAnt Directly 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. Click https://www.mailcontrol.com/sr/2xtGHdEPV0B0LscK46irk2g1Z03qwgtfeYY6hbKQ4rO6mI+hIUo9qtpkF2pfChzcyuvrFHpbOEqdliHTWaeclE34+SjjCFZhORFDZqCTqrAhCYDB!nRq0SOmUGlpvLOFsw5zchf1tA1rdXF22iXZvTebaX9IU9M5s9TeyHh5XB6mBSaQn!vSbSEEmUDkZc264E!Bs2X6yDj2vA9kFxMW9LtpSJwB50cG to report this email as spam. This e-mail, and any attachment, is confidential and is intended only for the use of the individual to which it is addressed. If you have received it in error, please delete it from your system, do not use or disclose the information in any way. The contents of this message may contain personal views which are not the views of the ECA Group, unless specifically stated. ------------------------------------------------------- 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
