How do you cope with releases of your custom Portal Content (PCD Content)?

Question

Dear SDN Community,
I'm very interested in how you cope with release management in the Portal (PCD).
Where I'm focusing on is the release of a "project" trough your landscape (Dev, Test, QA, Prod)
When starting a project you start with a new folder lets say "My Custom App" that contains all your content.
Once done you transport to Test, QA and eventually Prod. Now the Content is in use and roles are assigned.
Request for changes arive from the customer and eventually a new release need to be implemented.
Offcourse you could then change/update the content in the initial folder and transport that to Test, QA again but you will not be able to fix incidents while creating the new release because objects maybe touched.
I was thinking about a scenario where you create subfolders in your application folder, see example below:
\ "My Custom App"
|--- Release 1.0
|--- Release 1.1
|--- Release 2.0
|--- Current
You only do this on your Dev system. Everytime a Release is OK you put it in the "Current" folder and transport this to Prod.
Using this you won't have to change the Role assignments in your different landscapes as they are always pointing to the "Current" folder. In addition this scenario enables you to provide Pilot rollouts to smaller groups parallel to the Major release.
My question to you is to shoot on it and give your oppinion/feedback... where possible provide links to SAP document or best practices that describe this subject...
Thnx in advance,
Benjamin Houttuin

Answer 1

Hi Bejamin,
It is an interesting approach you describe and I see no reason it should not work.
The only thing which can create some problems is that the object ID of roles must be unique. For example com.mycom.roles.roleA cannot exist in two separate folders in the PCD. For all other PCD objects it is the PCD ID which must be unique and this includes the folder prefix.
In my experience, the most natural solution for this in large portal environments is to have both a version and a production line.
The production line will be your standard sandbox, development, test/QA, production and the version line will consist of an development and test/QA systems.
Long running projects for enhancements to existing functionality will be done in the version line, before being transported to the production line when ready for GoLive. This makes even more sense when you have version lines for backend systems your portal are using which are modified at the same time.
Whilst the project is running, the production line can be used for changes to the current version, but it is important to note that all these changes have to be migrated into the version line in order to make sure they are not overwritten.
Of course, a version line brings extra cost related to synchronization and similar, so it is not always it makes sense.
Amit's two documents of large portal installations might be somewhat relevant:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/bec9711e-0701-0010-e4ac-84f50543bfa9
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/25cab009-0801-0010-1380-edaa1d5e7f85
Regards
Dagfinn