[ic] site.txt in standard

Angus Rogerson arogerso at admmail.uwaterloo.ca
Tue Jan 26 02:57:59 UTC 2010

On 24-Jan-10, at 10:00 AM, Gert van der Spoel wrote:

> Hi,
> Quite a few developers (including myself) are using site.txt next to
> variable.txt to be able to split out some Variables that could be / are
> different in for example a development environment compared to the
> production environment.
> This split could also be useful when the site is kept up to date using 
> a
> version control system, where you can decide to for example ignore 
> site.txt
> so it does not get deployed to production ...
> I'd like to suggest splitting variable.txt and put some variables in
> site.txt .. catalog.cfg already has a line with regard to this, so it 
> will
> require only an addition in the dbconf/... directories similar to the
> variable.dbm ...
> The site variables are not shown in the admin under Administration, 
> but can
> be found still via the tables tab ... However this would be a 'todo' 
> for the
> admin UI ...
> Below the standard variable.txt , I've marked with a * the variables 
> which I
> think should be in site.txt ... Anybody has any other ideas?
> CU,
> Gert
> <snip>

We have been using a site.txt for a while to manage version control 
across multiple stores and development/staging/production environments.

To make our version control work, we tell cvs to ignore site.txt, and 
instead manage multiple files of the form site_<catalogname>.txt. When 
we create a new catalog, cvs dumps all the site_whatever files, and we 
create a symbolic link from site.txt to site_catalogname.txt. So in 
each catalog, there are a bunch of files, updated by cvs, which 
interchange does not know about:


and one link: site.txt -> site_ar.txt so that interchange only notices 
the right one.

In the book catalog, of course, site.txt is linked to site_book.txt

We also have 3 environments: development (where developers might be 
working on files in the interchange/ tree for various different 
projects with unpredictable results), staging (where we do final 
testing, and the interchange/ tree is stable) and production (which 
ideally is stable and well tested in staging). We use a similar 
strategy to the site.txt by having multiple versions of interchange.cfg 
(interchange.cfg.devel, .stage and .prodn). In each environment, cvs 
downloads copies of all the interchange.cfg.whatever files, and we link 
interchange.cfg to the appropriate one.

For some of the variables which Gert has indicated below, we build the 
variable from a machine name defined in interchange.cfg.whatever and a 
catalog name from site_whatever.txt. For example, in catalog.cfg we 
Variable   IMAGE_DIR  

By having the right variables in the right files we can migrate a 
catalog from development to staging (which are on the same machine so 
have some similar variables (for the machine name) and some different 
variables (for the staging vs development users)) and to production 
(which is on a different machine and has different settings such as 
merchant codes and production encryption keys).

So, ... I like Gert's suggestion. Careful consideration is certainly 
needed to get the right variables defined in the right files.


Angus Rogerson
Retail Services, University of Waterloo

More information about the interchange-users mailing list