nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Versioning Config Files

John742

Has anyone had any luck or experience in having TS/OD manage the crucial config files used by itself? I think this may "get" around some permission problems I currently have. I also see some issues that may come up, for instance a config file that is edited and subsequently breaks the workflow process. This process would be needed to edit and save the document that would fix the problem.

Find more posts tagged with

Comments

brandon1

Working at client currently that versions/deploys TS config files using Teamsite/OpenDeploy. One caveat you have alluded to is if you are managing the process via workflow and screw up available_templates than there could be an issue if you can not manually push an older version to the filesystem

Current Project: Content Services implementation

Migrateduser

Have you done a search? This has been discussed a few times already.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

John742

I have searched but I guess I have not hit upon the correct key word(s)

Migrateduser

Hmmm, I can't come up with a good set of keywords either. Maybe I'm looking in the wrong Forum. I could swear there was a lengthy discussion about this not too long ago.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

brandon1

Is this the one you are looking for?

http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=12667&page=&view=&sb=&o=&vc=1#Post12667

Current Project: Content Services implementation

nipper

I know there have been a numbe of discussions, though some may be > 1 year old.

IMHO versioning config files is a very good idea. You should do it.

However if you do, then you cannot use the admin GUi for any editing. That sucks. There is a FR for that,
allowing the GUIs (MetaTagger, TS, OpenDeploy) to change files other than in the $iw-home directory.

We version the config files, all changes go through workflow & (my) approval. No one edits
in iw-home (except me, but what good are double standards if you cannot use them ? )
This only happens in Dev, when we push to Prod, I run OD to push the config files.

Does this help ?

Andy

Migrateduser

That thread is pretty old. It is definitely one of the threads on this subject, but not the one I was thinking of. Of course, I could just be on crack and there is no recent thread. It's been known to happen...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

>That thread is pretty old.

no kidding, I was a lowly member & you golden. Boy you have gotten old quickly.

brandon1

Might want to switch to medicinal mari jane.

Current Project: Content Services implementation

Migrateduser

I'm playing around with this myself right now, but I'm moving away from using OD to actually do the deployment. That opens up the possibility of someone deploying a release to the production server that hasn't been through the QA process, so I'm just zipping the files now and letting the admin folks move them over. There's no great magic to it, just create a config branch that logically maps to the directory above where TS and OD are installed. Put one workarea in that branch, and check in the files that can be the same across all your environments. Make things as portable as possible. For instance, our odnodes.xml file lists all the nodes in our dev, QA, and prod environments - that way I can use one file for all three. For your OD and DD configs, use substitution parameters for anything that might change from one box to another. I changed the format of the opendeploy.cfg workflow file to use multiple sections so I can store my configurations for all the environments in one file. Put your non-environment-specific changes to iw.cfg in a separate file and write a script to iterate over them and add them to the actual iw.cfg with iwconfig -w.

Migrateduser

I've been old for a long time....it's only been since working at this job that I've gotten ornery as well.

OK, Mr. Smarty pants - how do I make a cool smiley like yours in my posts? All I know how to do is old school loser smileys Smiley Happy

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

can't believe you need to ask:

http://devnet.interwoven.com/forums/cgi-bin/faq_english.pl?Cat=#html

[ smile ]

nipper

>I'm playing around with this myself right now, but I'm moving away from using OD to actually do the deployment.
>That opens up the possibility of someone deploying a release to the production server that hasn't been through the
> QA process, so I'm just zipping the files now and letting the admin folks move them over.

I use OD for this. There are 2 scenerios, in Dev, as Smitty edits smitty.wft, he opens and saves and submits to
WF, in the WF process, it is opendeployed to the local $iw-home.

When Smitty's changes are ready to go to test (we use Dev Test and Prod TS servers) individual files are pushed
(by me via ftp) to the config branch on the test server. Dev has many projects at once, test only 1.
WF pushes the changes via opendeploy to the test server iw-home. On release day I push everything from the
config branch to iw-home on the prod server.

If you do this, make certain you exclude server specific files from open deploy. Files like iw.cfg, odnodes.xml,
database.cfg (for DD), have host names hard coded and need to be manually pushed.

HTH

Andy

Migrateduser

I have some code and even some docs that might work for you on this. Unfortunately the code sits on top of some modules I wrote which should have been provided by the vendor (not only are we all building the same wheels but we can't even use the same spokes), which you may or may not want in your environment.

John742

I would be interested in seeing what you have put together. I think this will give me tighter control over changes and by using OD it will ease permission issues that we run into with other depts. Since OD runs under a root account. I have the ablity to change files that are otherwise locked down

Migrateduser

Hi,

I think what I wrote uses File::Copy instead of OpenDeploy, but I think you could swap that out pretty easily. Send me a private message wth your email address and I'll send you the script.

All the best,

-John