Re: Deployment Strategies

A setup project might be complicated at first, but when you have keep
track of a lot of dependencies and inform the deployment team what files
has to be xcopied and keep track of what was xcopied to have a back out
plan, it pays off to put a little effort on the setup project the first
time.

-----Original Message-----
From: Discussion of building .NET applications targeted for the Web
[mailto:[email protected]] On Behalf Of brian zinn
Sent: Tuesday, February 13, 2007 2:56 PM
To: [email protected]
Subject: Re: [DOTNET-WEB] Deployment Strategies

For my last project I ran cruisecontrol.net continuous integration, we
didn't use QA or a staging environment for most releases.  Consider that
we
had high code coverage and confidence in our changes, although that's
not a
proper replacement for QA or staging.

Although it was a mission critical application - it was also internal,
which
is probably a luxury you don't have.  We simply xcopied all of the files
for
deployment!  Each site version was stored on the webserver for
roll-backs
(along with sql scripts, if necessary).  Our stored procedures were in
subversion, so we can link them to specific releases.  If you're worried
about uptime consider a webfarm and some type of session management not
tied
into the web server.  Even updates to web.config will cause IIS to
recycle.

If your sites are "updated almost constantly" then I think that is
generally
a problem in itself...  since you're in charge of the project you should
try
to limit that to scheduled releases if possible.  Sorry, but I'm just
having
trouble visualizing a site that needs to be constantly updated, yet is
well
managed!

Cheers,
Brian Z

On 2/13/07, Brian Vallelunga <[email protected]> wrote:
>
> This would be a really great plan if it weren't impossible for us. Our
> sites are updated almost constantly with very few scheduled large
> releases. I think we could use something more along the lines of a
> continuous integration and deployment system. What about other people
> out there?
>
> Brian
>
> -----Original Message-----
> From: Discussion of building .NET applications targeted for the Web
> [mailto:[email protected]] On Behalf Of Lizet Pena de
Sola
> Sent: Tuesday, February 13, 2007 9:21 AM
> To: [email protected]
> Subject: Re: [DOTNET-WEB] Deployment Strategies
>
> We usually build set up projects for the projects in the solution. The
> deployment team in our case has nothing to do with the developers, and
> the developers do not have access to the production servers. So in
order
> to make the deployment process easier and painless, we create a set up
> project for every project that needs to be elevated individually. For
> instance, one for the web services project, another one for the web
> project, another one for the intranet web project, etc. It mainly
> depends on where these projects will be deployed. When we create the
> build that will be elevated we label the files on that version in the
> source control system as, for instance, "deployed in V1.2.3"...
> Hope this helps,
> Lizet
>
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com