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; } } }

Having both QA & Prod branches on same TeamSite server

rohitspathak123

Hi

Using TS 6.5 SP1 Win 2003 .

We have a requirement in which both QA & Production BRANCH are on same TeamSite server installation .

There is no separate TeamSite server for Production .

Since we have two separate branches QA & PROD then DCT & TPL code present in the branches are different . If we change DCT or TPL code in QA branch , then this will not affect the code in PROD branch .

But now the problem is with common files like
1. workflow cgi & external task scripts ( that reside in iw-home\httpd\iw-bin )
2. Inline perl code used in DCTs
3. common user defined perl functions that are used in TPLs

So if we make some changes in these common files ....then those will be reflected in PROD branch DCT , TPL , Workflow also .....which we donot want unless untill the code in QA is stabilized .

Has anyone encountered such problem before .....what is the best sollution for this ...?

ONE SOLLUTION THAT I HAVE
-------------------------------------------

have two copied of the common files . ie., for QA branch the file name will start with 'qa' and for PROD branch the filename will start with 'prod'

for e.g., qaLockTransition.ipl & prodLockTransition.ipl

But main problem with this is that 'WE NEED TO CHANGE THE CALL OF THESE COMMON FILES IN DCTs , TPLs , WORKFLOW code also .....'

It will be very difficult to move the common code from QA to PROD .
If someone has a good sollution for this please share .

regards
Rohit Pathak

Find more posts tagged with

Comments

iw_store

Its better to have two different set of common files, in a separate folders one for QA and one for PROD. If purpose of these files are different w,r,t functionlaity in any sense.

if you are using exact copy functionality, then there is no use of having two sets, but you should touch common files in this box for Qa, whatever you do should be in development box and once that is successful over there can bring that to this box.

rohitspathak123

Hi iw_store ,

Thanks for ur reply !

But to again tell you I have SINGLE BOX on which I have two branches QA & PROD .
Also the functionlity of QA & PROD is same . Only difference is that QA is still under testing ...and PROD has the stabilized code .

Regards
Rohit Pathak

milind

We are also looking for same!!
Does any one has an idea?

Regards
Milind

iw_store

Hi iw_store ,

Thanks for ur reply !

Also the functionlity of QA & PROD is same . Only difference is that QA is still under testing ...and PROD has the stabilized code .

Regards
Rohit Pathak

I feel entire two different set of code for both in different directories.

John742

Question: When you say QA and PROD, from who's standpoint?
TeamSite Developers?
Web Developers?
Content Contributors?

Other considerations besides just templating may have to be taken into account here.

RonaldV

The very, very best solution I have seen so far is this:

- code your (perl-)functionality in a perl-module (a perl best practice any way)
- store these somewhere in your workarea
- make sure your perl-scripts etc. call these pm as soon as possible (e.g. no or minimal functionality coded in your scripts). Something like:

[PHP]use strict;
use YourLocator;
use YourModule;

YourModule->execute();
exit;
[/PHP]

When you do all the above you have 1 major problem left. The perl-script needs to know where to load the perl-modules from. This can be solved by:
- a perl module stored in iw-home/iw-perl/custom/lib
- this module needs to guess the current area location via the different way teamsite will pass this info to it. In cgi via the cgi-params, in wft-ipls via the ARGV[], in tpl via the iwpt-include param, etc.
- in the end this module should do a "use lib y:/path/to/your/wa/perl/lib;"
- in all perl-scripting this module should be "used" before any other custom-modules.
- in order to write a perl module like this you need to be fluent in perl because the trick is that this module should execute "on load" and not "on execute".

This way your code is versioned in teamsite AND seperated between QA & PROD.

Good luck, Ronald

Adam Stoller

Hi iw_store ,

Thanks for ur reply !

But to again tell you I have SINGLE BOX on which I have two branches QA & PROD .
Also the functionlity of QA & PROD is same . Only difference is that QA is still under testing ...and PROD has the stabilized code .

Regards
Rohit Pathak

I suggest you (or whomever is responsible for restricting you to one server for both QA and PROD) seriously reconsider what you/they are hoping to acheive.

The amount of extra work to needed to safeguard PROD functionality from QA verification of new DEV work is likely to be rather complex, time consuming, and difficult to maintain - especially given that TeamSite utilizes various files for server-wide configuration (e.g. iw.cfg) so that trying to verify a change to to such files is going to affect all users of the box - and not just one group.

The suggestion of using perl modules within workareas will get you part of the way towards a solution for the explicit issue you are trying to deal with now - but its not going to resolve all the issues that need to be dealt with in trying to maintain that kind of environment.

Migrateduser

Hi Rohit,

I see that the way you have structured your code itself makes it difficult.
May be you should be looking for a Strategy to move the code from QA to Production once its been tested and approved ( some thing like a release).
May be you can write a robust perl script to move the contents, which can be executed once your QA has been completed and you are ready to release