versioning nightmare

Trey

I am working on trying to do something I just can't figure out all the way, and would like some input.

I have 2 environments here. A Dev and Production Environment running windows 2003 teamsite 6.2. I am versioning my Interwoven custom configuration files (workflows, templating.cfg, etc.) for both servers on branches of my Teamsite Dev box.

Here is where I am running into a problem. I have a few configuration files that can be modified by content contributors via custom Perl scripts. I am trying to keep these specific configuration files in sync on both servers (in the workareas and on the server as well). Trying to come up with a way to keep them all in sync is driving me batty.

My initial thought was to create a script that does the following:
1. Reverse deploy these configs from the production server to the Dev box configuration branch for this server.
2. submit the changed files in the workarea.
3. deploy from the staging area to the the Dev environment and the Dev environment workarea.
4. submit the changed files in the Dev environment workarea.

the problem with the above plan is I am trying to start this process in my script only when the files are actually changed which happens on the production server. I can call the reverse deployment but the rest of the items need to take place on the Dev box. Any thoughts on how to do this?

Trey Wentz
Ferguson Enterprises, Inc.
e-mail: trey.wentz@ferguson.com

Adam Stoller

DNR as part of the deployment - that runs on the DEV box. It can get a list of the changed files from the in-memory log and then do the processing.

We're in the midst of wrapping up our upgrade (weeks away hopefully) - and we are going to be using a new code release procedure that sounds similar - but different - from yours.

We have all the customized files (configurations and pure customizations) stored in an IWHOME branch - that's mapped out exactly like the real IWHOME directory (we embedded the ODHOME and SEARCH pieced into the IWHOME branch even though they're actually distinct directory trees on the local disk).

We have one deployment configuration used to deploy files from the TS branch to the local disk; and another deployment configuration for deploying the files from the IWHOME branch on DEV to the IWHOME branch on TEST (and then again from TEST to PROD) environments.

Where necessary - we have files with envrionment-specific extensions - like "iw.cfg.DEV", "iw.cfg.TEST", "iw.cfg.PROD" (different license strings, hostname references, etc.) - and part of the DNR script used on the TS-to-local-disk deployment figures out which environment the current server is in and if it deployed any files ending with that environment extension - it copies it to the same named file without the environment extension (e.g.: cp iw.cfg.DEV iw.cfg)

We're still in the infancy of using this process - but it generally seems to be working thus far.

We don't have the issue with user-modification of any of these config files - they're all managed / maintained by us (the TS administrators / developers) - but hopefully the above will give you some ideas that you can use.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com