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

[Dan B]

Mike, Alan:

At 11:38 AM 3/24/2001 -0500, you wrote:
>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
>         directories.
>
>     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
>restarts.

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
>that price.

Definately a Quotable Quote.  That's going in my .sig collection immediately.

Dan Browning, Cyclone Computer Systems, danb@cyclonecomputers.com