WorkArea strategies?

Hi,

I am wondering what kind of strategies you would recommend regarding the number of workareas, and the allocation of jobs within those workareas. It seems clear that the sandbox philosophy involves each job being developed within its own private copy of the production site, in other words, one-job-per-workarea. As more jobs are undertaken simultaneously within a single workarea, that workarea becomes a poorer and poorer cimulation of the production environment, and the reliability of the work done their becomes increasingly suspect.

A number of problems naturally arise when multiple jobs are performed in a single workarea: inability to perform reliable link-checking, difficulty of determining which modified files belong to which job (ie determining a "publishing schedule"), etc.

Yet I get lots of negative reaction when I suggest that we should have some large number of workareas, and that editors should use a "vacant" workarea when they start a new job.

FYI, we are using TeamSite 5.5.2 on Solaris, with LDAP controlling all security/permissions.

thanks heaps,
Lee Borkman
Roads and Traffic Authority of New South Wales

Find more posts tagged with

Comments

Adam Stoller

If one may be so bold as to ask - what is the basis of the "negative reactions" you get for suggesting large numbers of workareas?

Frankly - the workflow itself could create a workarea on-the-fly, and then remove it on-the-fly before ending (upon a successful submission) - thus the impact of knowing which workarea you're in or need to be in, would largely be diminished.

--fish
(Interwoven Senior Technical Consultant)

gzevin

I think the question is too big to answer so easily. One has to understand your process, web structure, etc, to reccommend anything.

However, like Adam is suggesting, if you just need a workarea to do some dirty job and then submit, one could create it on the fly, get latest from staging, etc, etc

One of my clients in London did have a similar approach...

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Edited by gzevin on 01/23/03 09:42 PM (server time).

bjork

Thanks guys,

Just for background, we are a large state government organisation, with a 1000-page Internet, and a 10,000 page Intranet. We are looking at around 100-200 TeamSite end-users in the long-term. Our web-sites are non-frames, and have substantial all-site navigation included on almost every page. That navigation is created on-the-fly at generation time by examining the file-system and opening up related DCRs.

At any one time we have about 100 open jobs.

My basic idea is that we should create a set of maybe 100 workareas, possibly divided in some hierarchy to facilitate controlling permissions, etc. When an author in "Licensing" has a new job assigned to them, they look through the 10 Licensing workareas to find a "vacant" workarea, then they grab it, and proceed to do their job. If they are then assigned another job, they go and find another vacant workarea. The workareas would be kept up-to-date by a scheduled Get Latest script. When the job is completed, and the changes submitted, the workarea becomes vacant again, ready for the next editor to come along.

This would allow a job to be tested in isolation (ie in the context of an accurate copy of production). The list of modified files would give the user the list of files that need to be submitted - no need to disentangle file lists from multiple jobs. The navigation embedded within each page would be constructed based on an accurate copy of the production site.

But when I suggest this arrangement to our Interwoven resellers, they make the sign of the cross, and say that that many workareas would be a maintenance nightmare. At the moment, though, I cannot imagine what form that nightmare would take.

In short, one-simultaneous-job-per-workarea seems to be the logical and optimal situation. In your experience, are there practical factors that prevent one-simultaneous-job-per-workarea from being workable? To turn the question on its head, in what circumstances are we justified in having two or more jobs open in a single workarea?

Thanks heaps for your help,
Lee Borkman

Adam Stoller

I think the maintenance issue is a valid concern - and why I would advocate having the workareas created / and removed as *part* of the workflow operation - if you find a workarea sitting around for an extended period of time it probably means someone didn't finish a job - or maybe the reason for the job got cancelled (but the job itself did not, at least not in a clean manner)

Does it ever make sense to have more than one job being run within a single workarea - sure. When two or more jobs are related by context - but not with overlapping files (i.e. you should never have the same file in the same workarea associated with more than one job) - and when the two or more jobs are completely un-related.

In the first case, you're working closely to make sure that all the pieces fit together - but you will probably want to coordinate submit and deploy operations.

In the second case - where the work of any one job has no effect on another job, it's like two people sharing the same desk - one working on the right-hand side, the other working on the left-hand side and all work stays cleanly on one side or the other.

However - the notion of having a separate, clean, workarea for each new job is useful if not powerful, and if you can remove the human element from the maintenance of those workareas than it really isn't that much of a burden.

It takes a bit of extra code to adjust the workareas / areavpaths dynmaically like this but it's not terribly difficult.

--fish
(Interwoven Senior Technical Consultant)