You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by "John D. Leonard II" <jo...@ce.gatech.edu> on 2001/06/28 15:03:42 UTC
Strategies for version control of ASP pages
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.
To help simplify maintenance, I'm adopting a modular approach. I try to
isolate individual "panels" of a web page into their own ASP files, and
depend heavily on $Response->Include to construct the main page.
I'm familiar with CVS, but am unsure how to best leverage this technology
into a httpd environment.
Is anyone aware of "best practices" and/or "strategies" for managing the
development and enhancement of ASP sites? I've heard of DAV, but prefer to
use FrontPage as my editor, so I'm unsure of how to integrate the two.
Any URLs, suggestions, thoughts, comments, or words of wisdom would be
greatly appreciated!
JL
------
John D. Leonard II, Associate Professor Phone: 404/894-2360
School of Civil and Environmental Engineering FAX: 404/894-2278
Georgia Institute of Technology http://traffic.ce.gatech.edu
Atlanta, GA 30332-0355 mailto:john.leonard@ce.gatech.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Strategies for version control of ASP pages
Posted by JC Fant IV <jf...@hotmail.com>.
----- Original Message -----
From: "Joshua Chamas" <jo...@chamas.com>
To: <jo...@ce.gatech.edu>
Cc: <as...@perl.apache.org>
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: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
>
>
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Strategies for version control of ASP pages
Posted by Joshua Chamas <jo...@chamas.com>.
"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.
>
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: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org