[cgiapp] CGIApp Project Management

[Joshua Miller]

Developing on a central server is nice for dmz'd db access, and it saves
each dev from installing all the perl libs, apache, etc, on their own box
(or vm).

However, you'll have issues with multiple versions of libraries if running
like:

> http://www.our.server/cgi-bin/developer1/my-app.cgi
> http://www.our.server/cgi-bin/developer2/my-app.cgi
> http://www.our.server/cgi-bin/production/my-app.cgi

(unless that's a proxy to separate backend apache mod_perl processes)

Separate vhosts have similar issues.

I've split ours to separate apache instances, with high ports:

> http://www.our.server:8081/cgi-bin/developer1/my-app.cgi<http://www.our.server/cgi-bin/developer1/my-app.cgi>
> http://www.our.server:8082/cgi-bin/developer2/my-app.cgi<http://www.our.server/cgi-bin/developer2/my-app.cgi>
> http://www.our.server:8083/cgi-bin/production/my-app.cgi<http://www.our.server/cgi-bin/production/my-app.cgi>

Actually, we give each dev a range of 10 ports, so they can run multiple
versions of the app side by side. Just throw together a little apachectl
wrapper, and a base apache config, so they just have to include the base
config, and set a handful of vars to get their instance up.
Then they can start/stop their instance on their own, and no worries about
contaminated env or writing/reading someone elses files.

For version control, deciding on the merge approach usually answers most of
the related questions. See this for a starter background:
http://cvsbook.red-bean.com/cvsbook.html#The%20Dovetail%20Approach%20--%20Merging%20In%20And%20Out%20Of%20The%20Trunk
http://cvsbook.red-bean.com/cvsbook.html#The%20Flying%20Fish%20Approach%20--%20A%20Simpler%20Way%20To%20Do%20It

My 2cents... hope it helps, and good luck,
--
Josh I.

On Feb 12, 2008 3:27 PM, Dan Horne <dan.horne at redbone.co.nz> wrote:

> Barry Moore said:
> > Hi all,
> >
> > I've been developing web apps with cgi-app for several years now, but
> > for the first time I'm coordinating a project that will involve
> > several developers, and I'm trying to think about how best to
> > structure things - particularly in regards to version control.
> >
> > I've got three developers and I'm using subversion to manage code
> > versioning.  We are all developing on the same server (RH linux/
> > apache), and our "production" code will be on that same machine as well.
>
> When I've worked with multiple developers on CGI::App projects in the
> past, we simply installed a copy of the app on our own workstations. It's
> the cleanest solution, but it may not be possible for your team.
>
> > How do those of you with large groups manage having something like
> > this in each developers repository:
> >
> > /home/developer1/my-app-working-copy/cgi-bin/my-app.cgi
> >                                      /lib/My-App.pm
> >                                      /templates/home.tt
> >                                      /css/my-app.css
> >                                      /html/static.html
> >
> > distributed to something like this:
> >
> >
> > /var/www/html/my-app/css/my-app.css
> > /var/www/html/my-app/html/static.html
> > /var/www/cgi-bin/my-app/my-app.cgi
> >
> > I'd also like each developer to be able to run their working copy web
> > app off the same server so do you have different cgi-bin paths like
> > this:
> >
> > http://www.our.server/cgi-bin/developer1/my-app.cgi
> > http://www.our.server/cgi-bin/developer2/my-app.cgi
> > http://www.our.server/cgi-bin/production/my-app.cgi
>
> That's how I'd do it
> >
> > Or is it better to configure apache on this machine like this:
> >
> > http://dev1.our.server/cgi-bin/my-app.cgi
> > http://dev2.our.server/cgi-bin/my-app.cgi
> > http://www.our.server/cgi-bin/my-app.cgi
> >
> > I'm having trouble sorting our what problems to solve with
> > environment variables, which with config files and which with apache
> > configuration.
> >
>
> Your config file may need to reside outside of Subversion so that each
> developer's configured environment is not updated with the global one. If
> your code doesn't have any absolute paths, then things should be fine
> (e.g. use Findbin to set the Perl INC path relative to the cgi-bin
> directory)
>
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>