Promoting from sandbox to staging

[apoorvdurga]

When i create content in one sandbox and promote it to staging, it  not only automatically gets reflected in staging (which it should), it gets reflected in other users' sadboxes also.

Shouldn't it reflect in other users's sanbox when they actually ask for it? Is this intentional?

This is okay for content items but i guess it has the potential to break the code if done for JSPs on which multiple people might be working.

/a

[harrymoore]

This is one of the features I really like about Alfresco. I've worked with other systems where users had to take some action to update their area with the latest files. There is a page on the wiki that talks about this: http://wiki.alfresco.com/wiki/Collaborative_Content_Production

[kvc]

When i create content in one sandbox and promote it to staging, it  not only automatically gets reflected in staging (which it should), it gets reflected in other users' sadboxes also.

Shouldn't it reflect in other users's sanbox when they actually ask for it? Is this intentional?

This is okay for content items but i guess it has the potential to break the code if done for JSPs on which multiple people might be working.

/a

This is as designed.  Sandboxes are really to be used by two gross categories of users:  business users and developers.

A sandbox itself is a blank repository.  For business users, when we create a sandbox via the Create Web Project Wizard, we also create a layer for the business user's sandbox.  This layer provides a view of the the current contents of Staging.  Thus, whenever a new asset from another user has been previewed and approved in that user's Sandbox, the moment it is available in Staging (meaning it's the current working state or live version of the site) all other user's in their sandbox are previewing their changes against it.  This guarantees that every update to the site by a business users has always been tested against all approved site changes.

Other systems that support sandboxed development provide a fixed point-in-time view of the site against which business users preview.  This is problematic.  If changes were promoted to the site, the business user technically is testing their changes not against that current site, but some other past version.   You cannot guarantee that the changes they are committed actually work - they did against an older version, but not necessarily the current.  These system work around this by providing users the ability to update their sandbox with the latest changes.  This is a confusing operation for business users, however, and most forget or avoid doing it, compounding this preview problem over time.

Sandbox updating is really a developer feature.  At the repository level, sandboxes can be created that do not have a layered view on staging.  A developer can use our APIs to create a blank sandbox, update to the latest version of Staging, and maintain a fixed point-in-time view of the website that they can test against that is unaltered by ongoing check-ins.  From our API, developers can choose to update to newer content in Staging at their discretion - the exact model afforded by other systems that provide sandboxed development.

The web GUI for our initial release is more targeted for business users broadly speaking.  This means that sandboxes automatically have a layer created atop their sandbox to provide a preview environment for their changes against the current contents of Staging.  Greater control over whether a sandbox is fixed or dynamic (has a layer) and when a sandbox should be updated will be provided in future releases as we extend our web client to be more broadly applicable to developers.


Kevin