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
