Setting Up A True OOP structure for projects

Hi All...

I'm new to TeamSite so bear with me while I dip my toe into the water here Smiley Happy

We are using TeamSite 6.5.1 today for Web and Coldfusion development, we support a number of external and internal sites, the structure today looks something like this:

main
Intranet
intranet sites....
intranet sites....
intranet sites....
Internet
internet sites....
internet sites....
internet sites....

In each of those sites you would have development, staging and production workareas. Our engineers map the content store share and use that to normally work on their development areas (each developer gets their own workarea) and then when they are ready to submit, they use the teamsite interface.

We are now pushing the idea of having a code 'base' of re-usable components that would work across all our sites, for for instance we have a javascript toolkit that makes form validation simple and clean and consistent.
Today the same file (or in some cases revisions of it) are scattered all over the place, I'd love to have one place where all these shared pieces live and when they are updated the outlying sites would reflect that.

The core issue here is how do we accomplish that when we have multiple sites externally and internally? how are other people dealing with this issue?

I've thought of maybe using a top level directory below main to store these, engineers could then pick up new versions as they became availble. Or we could look at making them part of a deploy and use vpath's to point to that directory when someone is calling a shared piece...

Just looking to see what others are doing...

Thanks

-Paul-

Find more posts tagged with

Comments

blacke

I'm not sure if I understand the entire problem, but it sounds like if all the components are URL accessible, you'd update and deploy them to you're external intranet site and reference them with an absolute path. Only during development would you need to change the reference in the development site.

ISCBorisB

There are various ways to skin this cat. Since you did not plan that from the beginning, the easiest one
for you (with the least amount of changes in existing Branches) would be IMO something like the following:

Create dedicated Branch for Development, with desired WAs, levels of access separation and so on.
Do your development ONLY there, enforce technically and administratively if needed.
Create Workflow(s) to Publish an Edition and allocate components into Intranet/Internet Branches
using Open Deploy + perhaps GetLatest.

Your code will be versioned, you may have auditing trail, an ability to roll back, WF Approval steps and on...
An alternative is the integration with your Company Version Control like PVCS, Perforce, SourceSafe,
ClearCase, you name it

Sprockett

I think I need to describe out the problem further, and I also think I get where ISCBorisB is headed..

Let's say you have a .js file that you use for ALL your form validation regardless of the site, you support numerous sites and want an easy way to propagate any changes made to the .js without having to make everyone go and get the file. So in essence you would want any opendeploy pushes to include the latest release version of that file...

The question is how do you manage that, both within teamsite and open deploy, since the files in the global directory would in essence be in their own directory how would you manage changes and the need to propagate them?

If I had one project this would be a piece of cake, but when you start spanning external and internal sites you start running into setup issues (or rather the struggle on how to do it)..

Sorry if I was not clear before...

Thanks

-Paul-

nipper

Depends on what you are doing.

for JS, I keep mine in iwhome/httpd/iw/formapi

Then all DCRs can get to it.

For DCT and TPL, I use inline and iw_include to get the files from iwhome/custom/project/DCT or TPL.

The DCT inlines are Perl scripts so I use PMs to do preprocessing as well as generate common fields (like URL block). Then you change URLs once for all DCTs in the system.

All of this is on the config branch and pushed to iwhome via OD.

This is part of a best practice I plan to give at GearUp next year. Smiley Very Happy

HTH

Andy