[ic] Configuration management of store front (am I the only one that needs this)

Mike Heins mikeh@minivend.com
Sat, 24 Mar 2001 11:38:06 -0500

Quoting Young Family (ary@communicationfactory.com):
> What if I want to work on a "pending" store with proposed
> changes and then when the boss says it is okay, flip a switch and it is now
> the live copy?  I need to flip flop between copies so that there is always a
> "live shop" and a "proposed next version" shop? I am thinking that I just
> copy the live directory to a backup directory, and then that is that, but
> what problems will I come against? How do I keep the sales records rolling
> forward, but the catalog and web site content managed by a "flip-flop" type
> approach? What tables should always keep moving forward?.
> In other words,  using the "Akopia Three Tiered Approach"
> Technical Implementor
> Site Designer
> Store Administrator
> The site designer wants to work on a proposed site and see it functioning in
> a test mode before it is posted live. The we want to flip a switch and see
> the new content go public, ans start working on a new version offline again
> The store administrator does NOT want to go back and lose sales records, so
> there is no "configuration management" need for him.
> The technical implementor (poor old me) is trying to figure out how to make
> this happen.
> Can the many Interchange tables be identified as to their function and split
> out so that a version control/configuration management type system could be
> put in place?
> If this content configuration management feature were put in
> to place, this system would rival the Vignette Story Server big boys.
> What is the scope of a project that would add these features?

Pretty large. The key is the definiton.

Interchange is so flexible that it is hard to constrain it to a form
where you do this with a button. I think if you designed a catalog
from the ground up to allow this then you could. But it would require
discipline to stay within that framework.

After having done this many times, my suggestions are:

    1.  Identify the files that make up the new content. These usually
        include the pages/ directory, order/login/form profiles in
        etc/, the receipt in etc/, and the databases.

    2.  Keep your log and session files in a separate set of

    3.  Have two database DSNs, one for changing tables like
        orderline/transactions/userdb and one for the static product
        information. Inventory, if you have it, might be kept in the
        orderline/transaction area. That way, when you make the
	switchover, you can keep the table names the same without
        having to do anything but switch the base DSN.

    4.  Keep all growable files in separate directories.

    5.  Keep counter files in the logs/ directory with the growable
        files. (We don't do this in the demo.)

Once you have done this, it is a question of building a script that
saves the old, copies the appropriate directories over the old, and

The reason we have never done this in a canned fashion is that it
is so easy for people to break by using Interchange in a way that
doesn't fit those definitions. If we purported to do the switchover
and a variance corrupted their data, we would feel responsible.

There is a price to flexibility, and this is one of the line items to
that price.

Red Hat, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <mheins@redhat.com>

Nature, to be commanded, must be obeyed. -- Francis Bacon