I agree it's much easier to deploy with NAnt. My point on msi applies to web apps as well: I found out that when we do xcopy deployment, we get a lot of garbage on the production machine after a while.
In my experience, most developers don't care to remove files that are not in use any more, and any data-load/app bootstrap code quickly starts falling behind, as everybody somehow assumes that the server will never be re-built. Stuff like hard-coded guid references start popping up. I waged a lot of wars with my people to force them to re-build the database on each build, and export/import the data, still with mixed success. In short, I want to institute "ship every day" policy to the max. (Obviously, there are situations when you don't want to rebuild the db every day in production, especially with very large databases). [As an extreme, I remember back in my consulting days, people used to actually install visual studio on client's production server and do development/build right there]. I know of a lot of cases where people simply copy one pair of mdf/ldf (MS SQL server database image) as part of the deployment. There was this one guy who did that to the extreme -- he copied same database image _for two years_ on different servers as we evolved the application (We're in Europe and get to see a lot of different collations and formats on database servers, especially here in Switzerland). He left recently, and when I started inventorying stuff, I found incredible things in the database; and not just in the database: the asp app also got copied around and had tons of files like ".old", "old\xxx2001\", "copy of ...". This was both on our server (we use the app ourselves), and on the client's machine as well. On another ecommerce app we host for the customer, there were test accounts with admin privileges and usernames passwords of type "e/e", "xx" or similar, for the same reason. Anyway, I figured that only by using .msi and doing a whole rebuild of the environment I'll have a clean start in production. Not to mention that some people get "asp.net xcopy deployment" to mean "copy everything, source included", so you get all those <includes name="**/*"/> in the scripts. ("Just to be on the safe side"). Then again, if you're disciplined, (and hopefully you don't have to deal with horrors I described) your approach is probably equally or more productive as you have it automated end-to-end with the same technology. Damir p.s. Regarding your build folder structure: we do the same on the staging server, and have a vroot called /projectname/Latest that points to the last known good, so rollback involves just updating this vroot. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Morris, Jason Sent: Thursday, January 08, 2004 7:39 PM To: [EMAIL PROTECTED] Subject: RE: [Nant-users] Newbie question on using nant to push to production I don't rebuild the source either. The only time the source gets built is the initial move to development. Once that is built, then we copy the same bits to integration, pre-prod and production. So, our build process is Build to Development (new version number) Copy version x.x.x.x to Integration Copy version x.x.x.x to Pre-production Copy version x.x.x.x to Production This way our Promote target, i.e. copy to our integration environment, specifies which version of the web app to promote. <target name="promote" depends="env-int" description="Promotes CAPability to the Integration environment"> <property name="build.name" value="${project.name}-2.9.0.11" /> <property name="build.dir" value="${draco.build.dir}\${build.name}" /> <property name="draco.output.dir" value="${draco.build.dir}\output" /> <property name="db.scripts.dir" value="${build.dir}/dbScripts" /> <call target="info" /> <echo message="" /> <echo message="Promoting ${project.name} (${build.name}) to integration enviroment!" /> <echo message="" /> <echo message="Restoring and updating ${project.name}'s integration DB from latest backup of production..." /> <call target="update-db"/> <echo message="Updating ${project.name}'s web server..." /> <call target="clean-webserver" if="${doClean}" /> <call target="update-webserver" /> <call target="update-web-cachemonitor" /> <echo message="Running customer acceptance tests for ${project.name} (${build.name})" /> <echo message="" /> <call target="customer-test" /> </target> My group works only with internal customers, so we don't have to ship anything externally. We also completely control our production servers, so some of the things Damir was talking about are not much of a concern for us. Our web app is contained under one directory, so the event of a problem, we can wipe this one directory clean and copy back the last know good. However, on our build server, we do maintain a directory structure with each version of the build on it, so that if the new build is bad (somehow got past our unit and customer tests), we copy the bits from a previous build back to the production server. C:\prject.name\builds\1.0.0.0\ \1.0.0.1\ \1.0.0.2\ etc Just clarify my build process. Jason >Eric, > > >The step that moves the results to production is different than other steps, inasmuch as you should move the tested bits >from test/staging, not re-build the source. > >I prefer to use .msi installers for deployment -- you get uninstall capability for free, and also increase your >manageability, as you can much easier control what is installed on the machine remotely (through wmi, sms or the like). >Plus, .msi is easy to keep around in the archive, even after you purge older builds from the build server. And, you can >ship it remotely without requiring the user to re-create the build environment. > >If you deploy with NAnt script, you also have to write and test the uninstall script and have to keep around a exact >version of the NAnt binary you used, or constantly re-test with latest builds. > >Of course YMMV, as I don't know how often do you push your builds to production. > > >Cheers, > >Damir ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landes Eric (RBNA/CIT4.2) Sent: Thursday, January 08, 2004 5:22 PM To: [EMAIL PROTECTED] Subject: [Nant-users] Newbie question on using nant to push to production Just wanted to see if I'm on the right track here. Do others use nant (in combination with something like Cruise Control.net or Draco.net) to push builds to a production environment? I'm wanting to automate our builds hoepfully from development to test to production, and it looks like I could use these tools to get there. Of course from Test to Production would have to be controlled some type of flag to automate the deployment of the current version. I want to make sure that there's no pitfalls to this approach. I'd appreciate anyones comments, links or experiences with this. We're an in-house dev shop, with .net web apps. TIA ******************************************* Eric Landes Robert Bosch Corporation - Automotive Group ******************************************* Computer Information Technology Office - Engineering Applications 401 N. Bendix Drive - South Bend, IN 46628 Phone: 574-237-2290 Fax: 574-237-3105 ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users