[ic] Configuration management of store front (am I the
only one that needs this)
Sat, 24 Mar 2001 09:49:21 -0800
At 11:38 AM 3/24/2001 -0500, you wrote:
>Quoting Young Family (email@example.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
> > 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
I do some of this type of thing with CVS:
o CVS setup (lots of loginfo hacks to do this...)
o Build your catalog, and tag all the files STABLE or something
o /var/ic/catalog_stable (tagged STABLE)
o Then, copy it to /var/ic/catalog_devel (tagged DEVEL)
o Commits that are tagged STABLE:
o cvs update /var/ic/catalog_stable/$FILE
o Commits that are tagged DEVEL:
o cvs update /var/ic/catalog_devel/$FILE
o This requires loginfo will be smart enough to go to the right directory
to do cvs update $FILE depending on the TAG of the file committed.
A customized 'cvs export' works so that even though you are running two
catalogs (from one "CVS" filebase, mind you), one could pull the entire set
of a given tag into a new catalog ("PRODUCTION").
I'm still looking for a good editor that has CVS built-in,
though. (Besides EMACS).
>There is a price to flexibility, and this is one of the line items to
Definately a Quotable Quote. That's going in my .sig collection immediately.
Dan Browning, Cyclone Computer Systems, firstname.lastname@example.org