cancel
Showing results for 
Search instead for 
Did you mean: 

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

benjamin_houttuin
Active Contributor
0 Kudos

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

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

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-84f50543...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/25cab009-0801-0010-1380-edaa1d5e...

Regards

Dagfinn

benjamin_houttuin
Active Contributor
0 Kudos

Hi Dagfinn,

Thnx for your response...

One remark I don't get is why roles with the same name cannot excist in different folders?

We have working examples in our landscape (NW7.0 SP13)...

Based on the documents from Amit (I use them allot, they are superb!) we implemented the scenario where we make the "vanilla" copies of the business packages before we use them so than you automatically have two times the same role name in different folders...

I see what you mean with the parallel landscape for project next to the maintenance landscape... actually its exactly what we have implemented at the customer I'm currently working for. There we use a 6 system landscape Project-Dev, Project-Test, Dev, Test, QA, Prod. Indeed there is a tricky part getting the updates made in the productive landscape retrofitted in the project landscape but we manage.

When having such a landscape in place we still have the point that customers want to role out a new release to a small group of people first and then after lets say a month go full blown life. in these scenario's the folder structure I described could add value I thought because then the small group can already work with the new scenario (lets say the Release 2.0 folder) while the other users are still assigned roles from the "current" folder. Then when you rollout for everyone you make Release 2.0 the Current and transport in to Prod so everyone has the new release. As post action you remove the content and assignments you first made for the small group as they are no longer needed.

In addition to this aIl I must admit that I posted this question (based on my curiousity) to get an idea what other consultants and portal customers implement regarding this topic...

Thanks again,

Benjamin Houttuin

Former Member
0 Kudos

Hi,

Looks like you are correct (and I am wrong) with regards to the role id.

http://help.sap.com/saphelp_nw04s/helpdata/en/f6/29cf3d4f902d10e10000000a114084/frameset.htm

http://help.sap.com/saphelp_nw04s/helpdata/en/b0/2beb7a371c4649b2ceec901248ef31/frameset.htm

Pretty sure there used to be such a restriction just for roles, but it is not there any more.

Just out of curiosity, how do you handle the segragration of duties between the different teams in involved in a portal transports.

I don't like the idea that developers have the system admin role (since it contains way too much), and creating new roles is a bit of a hassle. Currently, developers are responsible for creating a textual specification of what objects to transport, and another team handles the creation of the transport package and import in target system (and a third team is responsible for approving changes to production by using an ITIL compliant tool)

We will go for CTS+ and then the developers will create the transport package themselves and the transport process will be much more automatic. However, it will be difficult for the third team to approve the change since the contents of the transport package is not know 100% (working with SAP on this problem, so it will come in the future).

Cheers

Dagfinn

benjamin_houttuin
Active Contributor
0 Kudos

Dagfinn,

Regarding the "segregation of duties between the different teams in involved in a portal transports" ...

First we copied the default content, user and system admin roles shipped default with the portal and created much smaller roles out of them. Almost implemented 1 role per navigation item... As an example Content Admin is split in a Role called "Content Admin - PCD Content" and "Content Admin - Translation'" etc etc.

In addition to that we created Developer roles per Project They don't contain content but are only used to set Portal permissions on the Project folders. So lets say for example we have a dedicated BW Portal and on that portal 4 projects are active. The project members cannot go tho the other folders so they cannot mess up eachothers content. Role maintenance is kept low as we share the customized admin roles between the projects. Central Corporate content like the framework and theme for example is managed by a central department. Projects need to adopt that. We also defined strict construction principles regarding SAP Portal that projects need to comply to. This helps us to build uniform Portal content/projects.

In some cases the project members create the transport packages in other cases "functional support" does it. But the actual transport is done by another person which is informed via procedures. We are also going to implement CTS+ a.s.a.p. because it will add value. Now we do it procedural and with a smart folder structure to move the packages through the Dev,Test,QA,Prod landscape.

Cheers,

Benjamin Houttuin

Answers (1)

Answers (1)

benjamin_houttuin
Active Contributor
0 Kudos

Because nowbody else participated in this questionaire I changed the status to Answered