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

[Young Family]

Hello
Of course! CVS is perfect for this purpose!
I will get something working and let you all know how it goes.
Alan Young
aray@communicationfactory.com

----- Original Message -----
From: "Dan B" <db@cyclonehq.dnsalias.net>
To: <interchange-users@lists.akopia.com>
Sent: Saturday, March 24, 2001 9:49 AM
Subject: Re: [ic] Configuration management of store front (am I the only one
that needs this)


> 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
>
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@lists.akopia.com
> http://lists.akopia.com/mailman/listinfo/interchange-users