multiple workareas

Hey,
I need some of your feedback on the new branching structure that I am suggesting to my client:

My client's current system:
1. They only have one TeamSite instance to do all dev/qa/prd work.
2. They have one workarea per branch and only source static content as of now (they do not create any content through TeamSite ie. no formspub/sitepub) and they wanted to move in that direction i.e.. to create content using sitepublisher and use LSCS in future.

The day-to-day problem I notice here is: there are multiple teams trying to edit same content in that one workarea and often overwrite each other's stuff.

My Suggestion to the client for the new implementation: Since they have multiple users working on same stuff, I thought we need to have multiple workareas:
• Multiple dev workareas for each team and one QA and one PRD workarea
• Workflow implementation: for each release we create new dev workarea’s for each team and get latest (so that it has all the latest prd content) and teams start working from there, once he/she is done, they will start the workflow and WF will copy that work into QA workarea (merge if there’s any conflicts) and deploy to some QA webservers, when QA team once done with testing will approve to push into PRD workarea and then submit to staging and push to PRD webservers and also creates an edition at last.
• In this implementation once, the release is pushed we will delete those temporary dev workareas we created for that release (having on demand dev workareas).

Now my concern is: I know this new branching structure will work perfectly if they still continue to source only static content. But will this work fine if they decide to use sitepublisher (or even formpub) to create content?
I have read in some of the threads that multiple workareas is not supported when creating content using SP/LSCS.

Can anyone suggest me a better option in my scenario?

FYI:
Env: TS 7.2.1/Linux

Find more posts tagged with

Comments

nipper

First and foremost, SP does not support multiple workareas per branch. One and only one.

Multiple workareas will mess up the sitemap editor.

So you need to resolve the issue creatively, multiple branches, workflow modifications and procedural changes. I cringe reading the post because they do not have a clue how to use this tool effectively. They think it is a hammer, they use it as a hammer.

sheikh1

Hey,

You approach is good as client is having only one TeamSite instance. My suggestion would be rather having different workareas for QA and PROD have a different branch for each QA and PROD respectively and configure your workflows to deploy from DEV branch to QA branch/Prod branch when need arises.
You can have multiple wokrareas in DEV branch, designating each workarea for each DEV team, else if you have all in one branch then it would be maintanance nightmare.
This legacy approach will work perfectly if you are using just Forms Publisher but for sitepublisher/lsds having multple workareas is still wokrable but not a recommended option, since your components/templates are created at admin level each team can have their own pages in the same workarea if it's acceptable, hoe this helps in suggesting a solution to your client.

Cheers,

Basheer

ISCBorisB

Hey,
I need some of your feedback on the new branching structure that I am suggesting to my client:

My client's current system:
1. They only have one TeamSite instance to do all dev/qa/prd work.
2. They have one workarea per branch and only source static content as of now (they do not create any content through TeamSite ie. no formspub/sitepub) and they wanted to move in that direction i.e.. to create content using sitepublisher and use LSCS in future.

The day-to-day problem I notice here is: there are multiple teams trying to edit same content in that one workarea and often overwrite each other's stuff.

My Suggestion to the client for the new implementation: Since they have multiple users working on same stuff, I thought we need to have multiple workareas:
• Multiple dev workareas for each team and one QA and one PRD workarea
• Workflow implementation: for each release we create new dev workarea’s for each team and get latest (so that it has all the latest prd content) and teams start working from there, once he/she is done, they will start the workflow and WF will copy that work into QA workarea (merge if there’s any conflicts) and deploy to some QA webservers, when QA team once done with testing will approve to push into PRD workarea and then submit to staging and push to PRD webservers and also creates an edition at last.
• In this implementation once, the release is pushed we will delete those temporary dev workareas we created for that release (having on demand dev workareas).

Now my concern is: I know this new branching structure will work perfectly if they still continue to source only static content. But will this work fine if they decide to use sitepublisher (or even formpub) to create content?
I have read in some of the threads that multiple workareas is not supported when creating content using SP/LSCS.

Can anyone suggest me a better option in my scenario?

FYI:
Env: TS 7.2.1/Linux

- Static Content / Forms Publisher

If I were you, I would go one step further.

Development, QA and Production has their own distinct life cycles. IMO, the way to reflect it is
by keeping them in dedicated Branches, not WA's of the same Branch.

So, propose multiple Development WAs in Development (sub) Branch, Start with the "medium strict"
Submit Locking Model. Make dedicated QA/Prod (sub) Branches with single WA each and restricted
direct access to this WA. That will allow you to keep Branches' WAs in Synch, cut Releases
(read "Editions") on all levels, maintain comprehensive versioning and so on.

Figure out you Client's Business requirement and practices and work out "Promotion" Workflows
Dev -> QA and QA->Prod. Rough Promotion schema is "initiate - [approve] - Process Source Branch,
[publish Target roll-back Edition]- "promote" modified Files to Target WA - Submit Target -
[publish Target Current Edition] - Deploy Current to Rendition Environment - Notify".

- Site Publisher/LSDS

Nipper addressed that a bit. You'll need SP/LSDS (and possibly LSCS if you plan targeting and the like) resource anyway

archanavonteddu

Thanks all for your wonderful feedback. I would definitely need to move towards having multiple branches instead of multiple workareas and have the workflow promote my content.