[Camps-users] question regarding setting up camp with interchange site

[Jon Jensen]

On Sun, 24 Jan 2010, Gert van der Spoel wrote:

> My set up for interchange is as follows:
> - OS: Debian Linux
> - DB: Mysql DB 5.0.51a
> - WS: Apache 2.2.9  ( /etc/apache2/httpd.conf )
> - IC: Interchange 5.7.4  ( located at:  /opt/interchange/  - actually that
> is symlink to /opt/interchange.5.7.4/   in case that matters)
> - CATROOT: /www/www.mydomain.com/catalog/
> - DOCROOT: /www/www.mydomain.com/htdocs
>
>  I read something regarding symlinking instead of copying.
>  In /www/www.mydomain.com/htdocs/images/  I have a couple of directories
> with my images which I'd prefer to not copy.
>  How does that impact the copy-paths.yml? I saw something about symlinking,
> but have the feeling that that would add
>  more complexity to the yml (I do not want to symlink all 'images'  just a
> couple of subdirectories).
>
> - CAMPHOME: /home/camp/    (here you will find /home/camp/bin/mkcamp  ..
> etc)
> - DEVHOME: /home/gert/     (under this user I'll want to be doing my
> development work)
>
> I'm having to put my interchange site still in git. I'm trying to understand
> what is required to be in git to make things work well .. Should I have
> *everything* in git?  All cfg's, images, etc? Any guidance in this area is
> appreciated.
>
> For now I will opt for the 2 tier approach, so DEV and PROD  (no
> UAT/TEST/STAGE).  The CATROOT/DOCROOT represent my production environment.
> Do I understand correctly that I'd have under /home/gert/xxx my repository
> where I will make my changes which I will then deploy to my DEV and PROD
> environments?
> So should I set up a /www/dev.mydomain.com/catalog  and
> /www/dev.mydomain.com/htdocs etc?

We have set up camps several different ways. Anything is possible. But let 
me describe what I feel is the best default way, which makes life the 
easiest, first:

Put everything in version control. Your Apache config includes (whatever 
parts you can do without hardcoded IP addresses or paths), Interchange 
(minus the bin/interchange wrapper that localizes the paths), catalogs, 
docroot (including all images if you can do it).

If you have hundreds of GB of images, that probably won't work, and then 
you can use the copy-paths feature. But if you only have a few GB of 
images, try putting them in version control. I've done it with up to 5 GB 
or so and yes, it bloats your repo a bit, but makes a lot of other things 
easier.

Next, put everything in a single tree, organized like this camp of mine:

$ tree -L 1 camp99
camp99
|-- bin
|-- catalogs
|-- cgi-bin
|-- htdocs
|-- httpd
|-- interchange
|-- migrations
`-- pgsql

The "migrations" directory is where we put SQL scripts for updating the 
database schema during rollouts. We test them in a camp, and refresh the 
camp database from production and test again right before rolling the 
schema change into production, so we're very sure it will work right even 
if weeks have passed since we first wrote the script. (And we have a 
history of migration scripts in Git.)

Finally, it's easiest if you set up a new home directory for production 
and make it work the same way, checked out from Git:

live
|-- bin
|-- catalogs
|-- htdocs
|-- interchange
`-- migrations

Except we use the standard distribution Apache and database, so there's no 
cgi-bin, httpd, or pgsql there. (Those aren't in Git anyway; they're 
created by mkcamp.)

Did this make sense?

Jon


-- 
Jon Jensen
End Point Corporation
http://www.endpoint.com/