Best practice of versioning perl, config and wft files?

TS 6.5 sp1, windows 2003

We have two ways

1. Use TeamSite branch for iw-home and keep the required files/dir in that branch.
...
2. Use VSS.
...

Please correct me if I am wrong in the above statements, please add your comments for best way of versioning.

I gernally opt for number 1. I think it makes the most sense.

#1 without question.

Had a very lively discussion on this topic at GearUp. I did a presentation that included this. It should be posted already.

I would go with option 2 because if the TeamSite server goes down you dont have access to your latest code.

Vrar

I would go with option 2 because if the TeamSite server goes down you dont have access to your latest code.

In my experience with VSS, its less reliable than TeamSite going down. But then again if either system goes down you will not be able to access your code.

13adam13

I go with Option 1, but federating the content to keep from having issues with the TeamSite locking me out of my development environment. Nipper's presentation from GearUp explained this process quit well.

the advantages of using TeamSite are numerous, amoung which:
- you already have the server
- you (should) already know how to use the tool
- you can create templates for many of the configuration files
- Teamsite has some excellent merge functionlity to manage conflicts
- OD is a wonderful deployment tool that you are probably already using, and it can deploy your code for you in an intelligent fashion
- DNR of OD makes it possible to reset the server, when needed
- Reverting when you break something is a snap

You dont keep any backup of the system on itself that makes more depended on that single system.

I would go with option 2 because if the TeamSite server goes down you dont have access to your latest code.

No you still have access to all the code in iw-home.

The only advantage of using VSS is that if you totally f*** things up (say in iw.cfg) then you can get the previous version and restart. If it is in TS, then you need to edit the iw.cfg and make the cahnge manually.

If that is a concern, you have no business editing iw.cfg.

Adam has nicely listed the many advantages to using TS to version your config files. Though there is one more, it is very easy for a developer to use. With the automatic deployment (and maybe even iwreset) it is much easier than VSS and is something that a developer can use for each change. A developer will not use VSS for each change.

Being a developer, anything that make my life easier is a good thing.

Andy

jbonifaci

Personally, I prefer option 2, but would recommend option 1 for others,

No you still have access to all the code in iw-home.

Murphy's law: "Anything that can go wrong will go wrong."

What if the System goes down and you can't restore it?

The only advantage of using VSS is that if you totally f*** things up (say in iw.cfg) then you can get the previous version and restart. If it is in TS, then you need to edit the iw.cfg and make the cahnge manually.

If that is a concern, you have no business editing iw.cfg.

If for some reason the iw.cfg file gets deleted then IT can restore it with waking up someone how knows it from the latest version.

Though there is one more, it is very easy for a developer to use. With the automatic deployment (and maybe even iwreset) it is much easier than VSS and is something that a developer can use for each change. A developer will not use VSS for each change.

Being a developer, anything that make my life easier is a good thing.

Andy

I might be old school but most developer's use VSS, CVS for source code versioning and its more easier the TeamSite.

Vrar

Wow this is getting interesting. Smiley Happy

If we are going to apply Murphy's Law to this, then no solution will help. Just as TeamSite could fail, VSS is much more notorious for becoming corrupt.

Is this server on any kind of backup? If it is, if TeamSite ever got to the point where it was completely unable to recover anything, this would be the point to call the admins responsible for tape backup and restore from that.

Otherwise it makes no sense to have a backup repository of another repository. That's what tape backup is for.

Murphy's law: "Anything that can go wrong will go wrong."

What if the System goes down and you can't restore it?

My point is that if there is a change that prevents TS from coming up you can go to iw-home and fix it.

If for some reason the iw.cfg file gets deleted then IT can restore it with waking up someone how knows it from the latest version.

Of course. I forgot about the old disappearing iw.cfg trick. Happens to me all the time.
Smiley Very Happy

I might be old school but most developer's use VSS, CVS for source code versioning and its more easier the TeamSite.

I have used plenty of systems like RCS, ClearCase, CVS, etc. However if I am a TS developer, I already have a TS window open, I can just pick the config branch, edit the file I need to change, submit it and it is in iw-home.

You can also turn off write access to iw-home to prevent unwanted changes. You can also do iwreset or even rebuild the GUI via a DNR if the change was something like ui_custom.xml. There are a number of advantages to using TS as a whole ot version these files.

Andy

Ultimately it comes down to the preference(s) of the individual(s) responsible for managing and/or customizing TeamSite.

If they really prefer using (CVS, RCS, SCCS, PVCS, VSS, P3, ClearCase, other) - then that's probably what they'll use.

If they're comfortable using TeamSite - that that's probably what they'll use.

Each system generally has some means of kicking off some sort of external process upon submit operations that will allow for some form of "workflow".

For the reasons already stated - I prefer using TeamSite to manage TeamSite.

If the iw.cfg (or similar) file gets corrupted, lost, or otherwise broken due to a change being made - you should be able to retrieve a working version from a tape-backup (perhaps even an on-line backup if using a NetApp box) to get things up again - and then you can diff the code on the local disk with the latest version(s) in TeamSite to determine what's wrong.

It's a slight imposition (the restore from backup) over the retrieve from some external code repository - and in my opinion, worth the imposition.

Frankly, if you wanted to - you could build into your "release" process a mechanism where each file that was going to be replaced was copied with a date-stamp extension so that if something failed you could just retrieve the older copy from right there on the local disk (and probably have some periodic process go through and clear out all but the last N copies of each file so as to not overly clutter the disk). I think it would be a waste of time to do so, but it's possible.

Srinivasa Talla

Wow, greate response, thanks for all.

Could you please address to specific issues like
1. If we are using VSS,(Need to map drive to copy manually or using script?)
a. how can we control different user/programmer without messing up other directories or files?
b. How can we able to restrict some users, without changing specific config files like(iw.cfg, available templates, templates)
c. How can we track changes to the files on TS(who copied, deleted,...)

I guess these are possible in TS.

2. If we are using TS, Can we able to compare different file types like xml, doc,..

3. Any info(pointer) about Nipper's presentation on this issue from GearUp?

Thanks
Sri

Wow, greate response, thanks for all.

Could you please address to specific issues like
1. If we are using VSS,(Need to map drive to copy manually or using script?)
a. how can we control different user/programmer without messing up other directories or files?
b. How can we able to restrict some users, without changing specific config files like(iw.cfg, available templates, templates)
c. How can we track changes to the files on TS(who copied, deleted,...)

I guess these are possible in TS.

2. If we are using TS, Can we able to compare different file types like xml, doc,..

3. Any info(pointer) about Nipper's presentation on this issue from GearUp?

Thanks
Sri

1. yes this is trivial in TS, write a WF and deployment, (I usually use the default submit and change).

2. You can do source changes (obviously not on a DOC file) on all TS files.

3. Heather said she would post the presentations, you may want to ping her.

me

I agree with fish on the most important point of this debate: TMTOWTDI.

I've done both, and frankly, find it a bit easier to use a real software configuration management tool for managing configuration than to use TeamSite. That said, if the group I'm working with doesn't have a real SCM, I'll be the first one in line to tell them to use TeamSite to manage TeamSite.

I agree with nipper that the "but what if someone kills TeamSite" argument is really pretty weak.

The biggest annoyances for me in using TeamSite to manage TeamSite is fairly specific to my role as a consultant. At any given moment, I may have several projects running side by side, and I generally will not have direct network access from my TeamSite box to the clients. One could publish an edition, go through the mapped drive and copy out the files from the edition, but I find it way easier to change the working directory in VSS and just do a Get Latest Version on the whole project. Similarly, it makes it easier to swap out entire codebases on a single server to meet the needs of different projects. It still doesn't solve the integration issue that Andy mentioned at his client where they have several different codebases all deploying into the same infrastructure. Only more hardware will solve that, and I am always in favor of more hardware (unless it cuts into the professional services budget Smiley Wink

)

So, whichever side of the argument you come down on, I hope we can all degree that any kind of configuration management is better than no configuration management. And renaming files from iw.cfg to iw.cfg.thisversionusedtoworkbutIdontthinkitdoesnowonmarch312006 doesn't count.

chunk

My eyes are a little blurry tonight so forgive me if I've missed this. Do you have a development TeamSite server? If not, are you doing all your ipl, wft, cfg, tpl, dct, etc. development on your production server? That's brave. Smiley Happy

Use your Production TeamSite server to house your dev TS server configs, code, etc. If the newly deployed stuff works on dev, continue the workflow and deploy to the prod TS server.

If you don't have a dev TS server, get yourself (or your client) a CVS or Subversion installation (both free, and reliable).

Using a single TeamSite server to house its own code is like keeping a spare key inside your house in case you lock yourself out.

Cheers

If you don't have a dev TS server, get yourself (or your client) a CVS or Subversion installation (both free, and reliable).

Using a single TeamSite server to house its own code is like keeping a spare key inside your house in case you lock yourself out.

I whole-heartedly disagree with that statement. If you do not have a dev server, it is even more important to version your files in TS. Why ? So you can use workflow and notification for approval of changes and you can lock people out of using iw-home.

I do not allow write access to iw-home on dev servers. NEVER would I allow write access (non-root/Admin) to iw-home on prod.

Your point about locking your key in the house implies if you screw up iw.cfg so bad, that teamsite will not run is a bad example. That would be prevented by proper WF and review. If an iw.cfg change was made on my system, I review it well before it goes to prod.

Root level access (or admin for DOS) to iw-home by developers on a production server is a very bad policy. OD can run as root and deploy where developers do not have access.

Andy

chunk

Andy,

Correct, no one but the TeamSite Masters and the OS admins should have write access to iw-home. That's why the promote to production step is a group task for the ts masters, not a developer or other user. The dev TS server can be open to developers to write to their own areas under local/config, local/bin, local/config/wft, etc.

But if you only have one TeamSite server you should not use it to house the code running that server. Forget messing up iw.cfg badly enough to take down the box. What if you mess up available_tempaltes.cfg? You won't be able to run the workflow to push the old one back out. Or, are you copying these files from within branches to iw-home by hand? If you're not taking advantage of TS workflows and templates then there's nothing "special" about TS at that point; it's just another versioning system.

Anyone from Interwoven Engineering wanna comment on what you do since you write TeamSite code and, I'd imagine, store it in a repository of some sort. Would you recommend using your only TS server to version your TS code? (Please, no one from Sales reply since we know the answer will be to purchase a development server. Smiley Happy

)

Good luck,

chunk

Anyone from Interwoven Engineering wanna comment on what you do since you write TeamSite code and, I'd imagine, store it in a repository of some sort. Would you recommend using your only TS server to version your TS code? (Please, no one from Sales reply since we know the answer will be to purchase a development server. )

Unless something has changed since I last worked there - Interwoven Engineering uses TeamSite to maintain all the code for TeamSite (and there other products) - yes, they have backups as any prudent IWOV customer would have - but the phrase which used to be used was "eat-your-own-dog-food", essentially meaning that if you don't trust your code for your system to maintain the code for your system - then you aren't doing a good job.

Andy,

But if you only have one TeamSite server you should not use it to house the code running that server. Forget messing up iw.cfg badly enough to take down the box. What if you mess up available_tempaltes.cfg? You won't be able to run the workflow to push the old one back out. Or, are you copying these files from within branches to iw-home by hand? If you're not taking advantage of TS workflows and templates then there's nothing "special" about TS at that point; it's just another versioning system.

chunk

True

If someone screws up available_templates.cfg, they cannot run the config WF. Then someone with root access needs to copy that file. This is the exception rather than the rule. I have implemented config branches at several sights and never had to manually copy or change a file (with the exception of setting up the WF for the config branch). I always use OD to move the files to iw-home. I also often have an optional DNR to iwreset (or even to rebuild the GUI if you want).

As Adam noted, IW engineering has used TS to manage all the code and configs for several years. That was the practice when I joined IW in 99.

Andy

chunk

Adam & Andy,

I remember that phrase fondly. I, too, used TeamSite to version TeamSite development when I worked for Interwoven. However, I used two servers. One, a default installation to version my code, and two, to develop on.

The question isn't whether or not TeamSite is the way to version the TeamSite code. The question is whether or not iwov engineering are developing and testing on the same machine they are using for version control, or do they have multiple machines?

Cheers

13adam13

The question isn't whether or not TeamSite is the way to version the TeamSite code. The question is whether or not iwov engineering are developing and testing on the same machine they are using for version control, or do they have multiple machines?

Since IWOV Engineering is probably handling *many* teamsite servers, as well as many other servers (WorkSite, LiveSite, SaleSite, ...), I think the answer is obvious. The question really should be if the risk mitigation of having a TS Server to maintain your TS code is sufficient to off-set the cost.

My experience, and apparently Adam and Andy's experience, is that the 1 or 2 times that you might have wished this was true is not sufficient to support the additional costs.

If you are really concerned that you are going to kill TS, and then have no way to recover because that is where your source code is, you can use OD to not only update production, but check files into your *free* SCM software.

jkm

Hi Guys,
This is a common issue for most of the TS developers. I have raised a FR 1236903 so that this should come as feature of TS to version iw-home.
Even IWOV support agrees they get quite a number of cases when people upgrade TS or apply new patches.

Please associate your company names with this so that IWOV take a serious thought on this.

Thanks!