[ic] site.txt in standard
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:
> 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
> version control system, where you can decide to for example ignore
> 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
> 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?
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
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.
Retail Services, University of Waterloo
More information about the interchange-users