LIVE Server Problem

[vijay_alfresco]

Hi,

I am using Enterprise 2.2 version of Alfresco. I configured three server Dev, QA and Prod, I selected Dev server and
deployed, now it shows LIVE in the Staging Sandbox, this is correct. And then I select QA and deploy, it show LIVE
in the staging sandbox and I cannot say this deploy is for QA..etc

But, can I have Dev LIVE or QA LIVE or Prod LIVE..etc so that I can know which server is LIVE.

Is this behavior can be achieved currently, if so please let me know how can this be done.

Thanks,
Vijay

[vijay_alfresco]

Any solution to this issue, can I put this into the JIRA??

[pmonks]

Because the staging sandbox is the final merge point for all change sets, it's basically the authoring side representation of the production system ie. you should design the system such that it only ever contains "blessed" content that is eligible for deployment to production.

The approach you describe breaks this model because at most points in time the staging sandbox will contain content that is both blessed (ie. has been tested in QA and approved) and content that is not yet blessed (ie. has been deployed to QA but is not yet approved).  This makes it virtually impossible to safely deploy anything to production, because virtually every snapshot will contain a mix of blessed and not-yet-blessed content.

The standard approach to content QA activities is to use user and workflow sandboxes in combination with preview, and as of 2.2 there are a number of ways to do this (virtualisation server preview, preview via test server deployment http://wiki.alfresco.com/wiki/Deployment#Live.2FTest_Server_Deployment, custom preview approaches eg. http://forums.alfresco.com/en/viewtopic.php?f=29&t=11845).

That said, if you absolutely have to be able to deploy merged snapshots in order to support QA activities, then an architecture with multiple "chained" Alfresco instances may be appropriate.  In this model you'd still have the original authoring instance (which content contributors use to create, manage and workflow their content), and it would deploy to a QA instance of Alfresco, in addition to any FSRs / ASRs that are needed to support the QA environment.

Once the QA activities are complete, that exact same snapshot would be deployed from the QA instance of Alfresco out to the production environment (FSRs / ASRs etc.).  In other words there are two semi-independent "tiers" of deployment: authoring to QA (to deploy not-yet-blessed content to the QA environment for the purposes of review / approval) and QA to production (to deploy blessed content to the live site).  The QA instance of Alfresco effectively acts as both an ASR (a recipient of not-yet-blessed content from authoring) as well as an authoring instance (as the initiator of deployment of blessed content to production).

Note that this model requires content managers to log in to two different Alfresco instances, depending on which type of deployment (authoring -> QA vs QA -> production) they are initiating.  In some cases this is an advantage (eg. different users are responsible for QA deployment vs production deployment), but obviously that depends on the make up of your content management team.

Cheers,
Peter