Hi Gunnstein, Hi Ekke, I also have a proposal that is similar to both of yours and might also solve some of Ekke's problems.
:: One installation, one tree, transactional, lockable, unlimited revisions and
no physical removal of content.
One problem I see is that we need to add new dimensions into informational
construct.
Currently we have the following dimensions in our architecture:
1st dimension: A list objects ( x )
2nd dimension: A lists of objects in a tree ( y )
3nd dimension: A lists of objects in a tree over object versions ( t )
Plus one new one:
4th Dimension: A list of objects in a tree over versions locked on the same
point of time (Stage)
To be successfully able to either stage a full or parts of the system we need
to be able to freeze or lock blocks( trees and related objects) of information
in our system and keep them in a sandbox/stage. A Stage would be a point of
time in the system where a block of information would get locked till it gets
unlocked again. When locked/staged no new element will get published on live
within that block. Blocks of the same or partly the same information in
different stages can get merged ( Stage 1 + Stage 2 merge to Stage 3). When
editing content editors can decide in which stage they want to see and edit
content.
One installation, one tree, transactional, lockable, unlimited revisions and no
physical removal of content.
Pros:
+ Approve only a subset of changes
+ Instantly applicable to LIVE within one database transaction
+ Flexible
+ Short development time, if we do not introduce merging
+ Unlimited revisions
+ Locking
Cons:
- We need the concept of not lockable objects (e.g. Users)
- Merging content requires manual work and is cpu intense.
- Brings complexity of the editor
- Requires immense storage. Solution: Only store the differentials.
Did you notice something? I think this is the system we use in our daily life.
It is subversion.
Best regards,
Björn Dieding
Content & Commerce made easy
GMT +01:00 Hannover, Germany
Björn Dieding
Phone: +49 (511) 5904576
Mobile: +49 (151) 12169868
Email: [EMAIL PROTECTED]
PayPal: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
YIM: bdieding
AIM: BjoernDieding
ICQ: 176927179
SKYPE: BjoernDieding
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:sdk-public-
> [EMAIL PROTECTED] On Behalf Of Gunnstein Lye
> Sent: Friday, January 18, 2008 4:23 AM
> To: [email protected]
> Subject: [Sdk-public] Staging solutions
>
> Hi all!
>
> I have been discussing staging with a customer. If you have any
> suggestions or
> experience in this matter, I'd be grateful. It seems to me that this kind
> of
> staging is not really possible unless staging features are built into
> every
> part of the system. But I could be wrong. These are the alternatives we
> have
> discussed:
>
> 0. Preface
> - The system should be split in two: a staging part and a production part.
> They do not have to be different servers or even different eZ Publish
> installations.
> - Staging requires login, production does not (obviously).
> - There are several editors producing content, and several administrators
> approving content.
> - It must be possible to preview the complete state of the staging server
> before content is approved. This rules out the standard approval workflow,
> because it does not publish content until it is approved.
> - The editor activates a mechanism that sends an email to the
> administrators
> - The administrators get a mail with a link to the content, where they can
> approve or deny.
> - Enhancement: A feature for reverting and merging changes, like in svn.
>
> 1. One installation, two subtrees
> On approval, content is copied from the staging subtree to the production
> subtree using a custom module.
> Pros:
> + This can at least theoretically satisfy all the requirements in my case
> Cons:
> - Copying content is simple enough. But there are many other possible
> changes,
> like moving/deleting content, and changing section, relations, priorities,
> sort order and visibility flag. This is complex and requires many kernel
> hacks.
> - Add to this that some edit actions are dependent of others, one cannot
> be
> approved without the other. Example: #1 Create article A, #2 delete
> article
> A. Here, #2 cannot be approved until #1 is approved. This adds complexity
> and
> development time.
> - Without a feature for reverting changes, the staging content could soon
> become so different from production that efficient change management is
> impossible.
>
> 2. Two installations, syndication
> Use the syndication extension to transfer content.
> Pros and cons: Similar to nr. 1.
>
> 3. Two installations, replication
> On approval, content is transferred to production using database
> replication.
> Pros:
> + This provides complete replication of every possible change on the
> staging
> server
> + Very quick
> + Short development time
> Cons:
> - Requires cluster setup (files in database)
> - Problems with cache files in database
> - Problems when you have content produced on production, like article
> comments. This can be solved though.
> - Impossible to approve only a subset of changes. It must be all or
> nothing.
> (This is a showstopper in my case.)
>
> best regards,
> --
> Gunnstein Lye
> Systems engineer
> [EMAIL PROTECTED] | eZ Systems | http://ez.no
> --
> Sdk-public mailing list
> [email protected]
> http://lists.ez.no/mailman/listinfo/sdk-public
smime.p7s
Description: S/MIME cryptographic signature
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
