----- Original Message -----
From: "Joshua Chamas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 9:50 AM
Subject: Re: Strategies for version control of ASP pages
> "John D. Leonard II" wrote:
> >
> > All:
> >
> > This question is not directly related to ASP, but more to the web site
> > development and maintenance process.
> >
> > I am having trouble maintaining all the ASP pages that I've been
creating.
> > I'm finding myself working directly on (and often experimenting) with my
> > production system, often screwing things up while someone is trying to
> > access my files. I'd prefer to work on a development system, then
deploy to
> > the production system, using some sort of "versioning" or source
control.
> >
Planetofmusic.com is using CVS for all of the dev work with ASP. We setup
seperate playgrounds for all of the different developers and allow them to
commit the work when they arew finished... this is probable what you need.
Setup a dev server that will allow for apache to run multiple playgrounds
that will house a full version of the code on your site.... then all you
have to do is use CVS to commit files. This works well especially if u use
build tags to update from your dev enviroment to stage then to live... you
will be able to update the live site just using cvs update <build>.
>
> There's staging & source control. I'm an expert at neither.
>
> For staging, a simple model is to have a dev server separate
> from the production server, ideally identical. One can do
> this on the same hardware by running a separate web server
> on a high port for dev purposes.
>
> A more complicated staging version, is where you have dev servers,
> qa servers, & production servers. This is useful is someone
> else is running QA while you are developing, and you can work
> concurrently to their QA efforts.
>
> If the high port model is used for multiple servers, I would suggest
> making the perls independent, and each apache httpd built separately
> with these perls. The issue is what happens when you have to install
> or upgrade a CPAN module, usually this would be installed into the
> base perl, but if this is used by both prod & dev, then you will hose
> both servers at the same time. Better to have separate perls, upgrade
> your dev server perl first with the new cpan module, then upgrade
> production after you have QA'd your work.
>
> Make sure too to install perl in very separate paths like:
>
> /usr/local/perl561_dev
> /usr/local/perl561_prod
>
> so there is no chance that the libraries will mix.
>
> The staging process slows tweaking down too, as you end up with
> slower release cycles just because of it being more work to
> publish. I just use rsync to push out new code to production,
> others might use their source control system to do this.
>
> When it comes to source control CVS sounds fine, though most
> of my work has been with perforce lately, a commercial
> source control system. A good CMS like this can facilitate
> dev/qa/production releases with proper labeling and branching
> in the code lines.
>
> --Josh
>
> _________________________________________________________________
> Joshua Chamas Chamas Enterprises Inc.
> NodeWorks <- Web Link Checking Huntington Beach, CA USA
> http://www.nodeworks.com 1-714-625-4051
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
