The short answer is to manage replication by collection. Collection is a good unit for this type of management because of its open ended definition. A collection is just a bunch of stuff that goes together. So people tend to naturally understand and even expect that a collection as a whole will have the same state.

Note, some collections will flow "upstream" in that a bunch of revisions will want to follow the Development/QA process from Development, Integration Testing, User Acceptance and Production. Other collections flow "downstream" in that the content is updated in Production on a regular basis and folks like to see the current content in the various test environments to make sure the UI is correctly pulling things out by date, subject, etc.

Of course, it gets tricky when you have updates in production on collections that flow upstream. I have found these are relatively rare and the times you need to merge changes, rarer still. These are best done by hand.

The specific mechanisms for tracking the status and actually performing the replication are, of course, product dependent.

take it easy,
Charles Reitzel


At 05:45 PM 11/23/2002 +0000, Drew McLellan wrote:
(I sent this several hours ago, but it didn't show up. Apologies if you get two copies).

My CMS has a very simple (too simple) staging/deployment setup at the
moment. In our next rev, I'd like to improve on it.

I basically have two matching databases containing the data for the
site. All content changes go into the staging db, and the staging site
uses this db so you can preview changes in context.

When all the changes are approved, the content is deployed - the system
copies the changes from the staging db to the live.

This means that you can't selectively deploy changes - it's all or
nothing. Fine for small sites - but no good otherwise.

My question is, how do other people deal with selective deployment at a
conceptual level? Here's so ideas I need to flesh out:

* deploy on content type level (I don't think this works for me)

* create 'change groups' and get content authors to specify which group
a modification belongs to when making the modification, or within their
session. deployment by group. (how do you deal with content
interdependencies?)

* date based deployment - deploy all changes before date x. (again,
interdependency problems?)

* flag items of content ready for deployment, and only deploy those?

* have the deployment routine list all changes and allow selective
deployment in that way?


How do you eat yours?

thanks!

--
drew mclellan

web standards project
http://www.webstandards.org/


--
http://cms-list.org/
trim your replies for good karma.
--
http://cms-list.org/
trim your replies for good karma.


Reply via email to