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

[Brian J. Miller]

Jon Jensen wrote:
> 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).

Shouldn't add complexity to the .yml as the paths are the same. What it 
does is allow you to symlink specific paths rather than needing to copy 
all of the files. So the couple of subdirectories that you don't want to 
copy all of the files from you just symlink which should be the same 
paths that you would be specifying anyways. Also note that you can 
always choose whether or not to symlink so if you need to copy them for 
some reason you still can.

>>
>> - 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.)
>

I've at least been using the convention such that migrations has two 
directories underneath it, pending/ and applied/. So scripts that are 
still pending being applied to production are stored in pending/. Then 
during a release cycle at the time that I "apply" such scripts to 
production I create a directory underneath applied/ using a time stamp 
of the point at which they were applied, so applied/20100125_1242/, then 
I move the files from pending/ to the new directory for historical 
purposes. All of this gets tracked via git. I was also storing a dump of 
the database at release time in the applied/<ts>/ directory, though Jon 
didn't like that for one of the projects. YMMV.

> 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?
> 

In response to the steps you previously outlined and doing the whole 
tmp/* copy thing in /home/camp. I've taken to using the convention where 
you just do a git clone into /usr/local/camp then symlinking from 
/home/camp/bin -> /usr/local/camp/bin, /home/camp/lib -> 
/usr/local/camp/lib, etc. That way you have an easy upgrade path for 
camps, aka you just git pull and test. Eventually I'd expect the camps 
to be more of an installed thing, but for now that works well and you'll 
be an expert by the time camps is truly installed.

-- 
Brian J. Miller
End Point Corp.
brian at endpoint.com