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,wft and perl files

Srinivasa Talla

Hi, Can you please suggest me for best practice of versioning config,wft and perl files.
Can I able to use TeamSite 6.5 or any other Source code versioning tool?

Thanks
Srini

Find more posts tagged with

Comments

dazzlad

Create a branch in TeamSite that mirrors iw-home.
Use Opendeploy to deploy editions to the real iw-home.

Darren.

nipper

Take a sample WF and configure it for approval if you need. I usually just use 1 Workarea, and deploy from
Staging to iw-home

Can also use it to release your code from the dev server to prod, in that case I exclude OpenDeploy config files as
well as iw.cfg

Srinivasa Talla

Create work area, and mirror iw-home. But whenever a developer is changing a file
(even single line of code), he needs to

1. submit for staging, then invoke a deployement. OR
2. invoke a deployement(from workarea)

We need to write a workflow to do the file/directory deployement.. and again
initiating the process?

Usually people will use this process? or is there any alternate easy way?

jbonifaci

Depending on your definition of easiest, it doesn't always go together with best practice. But it is easy enough to create a submit workflow that requires no approval where the developer can just select their file(s) and hit sumbit. The submit workflow then does the easy tasks of submitting and copying/deploying the files to the appropriate location.

~Jeff

dazzlad

This is just off the top of my head, I haven't really validated everything yet.

I like the idea of having a dev TeamSite server which has iw-home mirrored in a TeamSite branch.
For this dev server:

1. Add an at trigger on lock that moves the file(s) concerned to iw-home and makes them writeable.
2. Add an at trigger on unlock that moves file(s) from iw-home back to the TS branch and makes them read only in iw-home.

This is mirroring standard source control check out/check in functionality and allows you to develop and test without having to trigger a deployment for each file change.

Once a developer finishes modifying a file, they can submit (with comments). Publish an edition and deploy to the production server.

Darren.

jed

I am of the opinion that code/config/etc should be stored outside of teamsite. We use CVS to version all of our code. When we migrate to another server, we use ant to create a zip package of all the code. Why?
o more people know CVS than TeamSite. Part-time developers do not need to bother learning TeamSite
o parallel projects in our group use CVS, so people working on multiple projects always access their code in a consitent manner
o if the dev server goes down, the code repository does not go away
o if we change our CMS in the future, we do not need to change our code repository best practices

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

Johnny

Jed, I'd love to get more details about your ant build process. I looked into it a few weeks ago but I wasn't sure how well it would fit with our development.

There are a couple of things we'd like to manage that I was unsure how to do. The first is to be able to maintain a filelist/manifest of each project/website separately and create builds accordingly. I figured that could be done with separate ant scripts somehow.
The second was to have some way of managing certain files, mostly config files, that are environment specific

The idea was like the following example -

etc/iw.cfg.hostname_prod_server
etc/iw.cfg.hostname_dev_server
iw-home/local/config/templating.cfg.hostname_UAT_server
iw-home/local/config/templating.cfg.hostname_PROD_server

OpenDeployNG/etc.hostname_dev_server/
OpenDeployNG/etc.hostname_prod_server/

The build process would grab all environment specific files if the general name was sepecified and the install process would use the server specific file if it existed.

The current TeamSite setup is quite clunky for developers as far as I see it. Files seem to be scattered throughout the install base and some must even share the same directories as product files (iw-home/httpd/iw-bin). This makes it quite tricky to maintain/track all custom code as time goes on without a proper build/install process.

How would/do you address these points? More specifics on your ant build and any install steps would greatly be appreciated.

IWOV would be taking a big step forward in bolstering stability and quality of custom code if they took a serious look at how code is left to be managed compared to other enterprise class systems.

John Cuiuli

dazzlad

>> if the dev server goes down, the code repository does not go away

But if the CVS server goes down then it *does* Smiley Happy

Darren.

dazzlad

I tried to kick off this kind of discussion in this post. But it seemed to go down like a lead balloon.

It would be very cool to have some input on using ant to create packages in this thread.
It would be even cooler if a few senior heads thrash out some guidelines for best practices when managing TeamSite config.

Darren.

Adam Stoller

I've used TeamSite to manage TeamSite config files and such - but perhaps this will help in your situation too.
What we did for environment specific files is we versioned the files as:

iw.cfg.PROD
iw.cfg.TEST
iw.cfg.DEV

etc., and then our OD process for deploying the files from TeamSite to the local disk used a DNR script that determined (based on the hostname) what the current environment was (PROD, TEST, or DEV) and then looked through the list of files having been deployed - and if any of them ended with ".<current_environment>" it performed a copy of the file without the environment extension.

I.e.: if iw.cfg.PROD was deployed on the DEV system - nothing happened in the DNR script. However, if iw.cfg.PROD was deployed on the PROD server, the DNR script would do a copy of iw.cfg.PROD to iw.cfg.

Pro: The environment specific files got where they needed to be
Con: The environment specific files for the *other* environments were all deployed on all environments.

A big plus for me was the ability to move the replicationFarmSet definitions from the deployment config files to the odnodes.xml file in OD 6.0.2 - this meant that we only needed variants of the odnodes.xml (and odbase.xml) without requiring variants for each deployment config file.

In TS 6.5SP2 - they changed the licensing mechanism to use a separate file, instead of the license string settings in iw.cfg as per previous releases - this helps reduce the variances of iw.cfg for the different environments (especially if you can use 'localhost' for the 'host' settings) - I think if IWOV could do a better job of separating out host-/environment-specific settings from 'generic' settings it would go a long way to simplifying this kind of process.

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

jed

We keep most of the code/config in logical buckets/directories within our CVS structure. In theory, people only need to care about the code/project that they work on. Our ant scripts glue everything back into the magical filesystem locations within a zip file that is eventually deployed onto the production server. For example, we have the following:

./workflow
./workflow/wft
./workflow/bin

The ant script will put the stuff in the proper locations within a zip file such as:
/app/suncom/iw-home/local/config/wft/foo.wft
/app/suncom/iw-home/local/bin/script.ipl

As for the host specific stuff, we have a "config" bucket. When the build is started, we pass a host name. Based upon the parameter, a specific directory is used with the proper config file.

./config/star-dev/iw/iw.cfg
./config/star-dev/opendeploy/etc/odnodes.xml
./config/star-test/iw/iw.cfg
./config/star-test/opendeploy/etc/odnodes.xml
[...]

So, if ant is invoked like so:
ant -DiwHost=star-dev

The configs for star-dev are pulled out.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

Tbag

We have a TS dev server and TS prod server with a custom version control structure set up to migrate changes between the two.

Note: This whole solution is based on the assumption that the TS admins/developers WANT to use the command line more than the GUI....

On teamsitedev, we have the following branch structure:
/default/main/admin/dev ------ for source controlling scripts, etc. that we'll eventually release to teamsiteprod
/default/main/admin/release ------ for cutting editions and deploying final scripts to teamsiteprod
/default/main/admin/local ------ for source controlling files (like iw.cfg) that should never be blindly copied between servers

On teamsitedev, we have a script named "ci.ipl" (ci = checkin) that allows admins/developers to copy a file out on the "live" filesystem to the appropriate source control branch. The script is smart enough to know, for example, that iw.cfg should only be checked in to the "local" branch.

The ci.ipl script also supports a --deploy flag that cuts an edition of the admin/release branch on teamsitedev and OpenDeploys it up to teamsiteprod.

I'm attaching the ci.ipl script for anyone who is interested. Note that in our installation, the "TeamSite" and "OpenDeployNG" directories are both under a C:\Interwoven directory and that assumption is used a couple times in the script. Also, note that the Windows installation makes path creation and resolution a little annoying.

Tbag

Oh yeah, and here's a script that runs a diff betwen the different source-control branches and the "live" filesystem and reports all the differences between the two...this is helpful for when you're working on a release involving a dozen files or so and you forget to write one down.

Adam Stoller

Thansk for sharing, looks pretty nice. A few comments for you to increase portability of the script a bit:use TeamSite::Config;
use XXXXX::Commons; # all you need is a function for "on_teamsitedev()"
my $srchome = "C:/Interwoven";
my $iwbin = $srchome . "/TeamSite/bin";
my $odhome = TeamSite::Config::iwgetlocation('iwodhome');
my $iwhome = TeamSite::Config::iwgethome();
my $iwmount = TeamSite::Config::iwgetmount();
my $tracelog = `iwgettrace.exe`; chomp $tracelog;
(my $srchome = $iwhome) =~ s{/[^/]+$}{};
my $iwbin = "$iwhome/bin";
my $tracelog = TeamSite::Config::iwgetlocation('iwtracelog');

#
# Define logging structure
#
# For logging, either hardcode a log file, or add a logfile definition
# in the etc/iw.cfg [log_files] section named 'mynewlog=abc.log' and
# lookup the path to the log using the IW_cfg functionality.
#
# consider using Log::Log4perl
require "$iwhome/local/bin/boilerplate_logger.ipl";
my $logfile = "$iwhome/local/logs/ci.log";

Also - instead of: if ($release eq "1") { try either: if ($release == 1) { or: if ($release) { (the last assumes a simple boolean test, 0 = false, any other value = true)

Also - to make the script more portable - leave off the '.exe' extension on all the CLTs you call - I don't believe you need to specify it on Windows, and you definitely don't want it on Unix (if need be you can set up a conditional $ext based on the value of $^O)

I'd probably make some other changes - but I think they're more on the stylistic level (I haven't read your entire script yet)

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