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

CSSDK Development with multiple developers

Adam Stoller

I've come across this issue before, and never felt I had a "good" answer, so I figured I'd throw it out here and see whether any of you have dealt with this before and how (if successful).

Scenario

Has anyone found a good strategy for having multiple developers work on CSSDK code on a single TS server without causing significant disruption of their colleague's work?If so, details of the setup would be useful to know.

Find more posts tagged with

Comments

Migrateduser

This may not help you as it requires people to have to update their codebase manually to stay up-to-date, but we had a similar problem and this "helped". We have installed TeamSite on VMs on developer's laptops so that they can essentially develop in their own sandbox. Of course you have to download everyone else's changes ad hoc and upload your changes as well. But it allows you to get a lot of initial debugging and unit testing done without hampering anyone else's progress. It may not be an option for you, but it is an option.

interDev

This may not help you as it requires people to have to update their codebase manually to stay up-to-date, but we had a similar problem and this "helped". We have installed TeamSite on VMs on developer's laptops so that they can essentially develop in their own sandbox. Of course you have to download everyone else's changes ad hoc and upload your changes as well. But it allows you to get a lot of initial debugging and unit testing done without hampering anyone else's progress. It may not be an option for you, but it is an option.

Will it not create licensing issues as you would run multiple instances of Teamsite development env. in this case (although you would be licensed for only 1 development environment)?

RonaldV

I suppose it is either multiple vm's or junit. But junit is not the same as "the real thing".

Adam Stoller

This may not help you as it requires people to have to update their codebase manually to stay up-to-date, but we had a similar problem and this "helped". We have installed TeamSite on VMs on developer's laptops so that they can essentially develop in their own sandbox. Of course you have to download everyone else's changes ad hoc and upload your changes as well. But it allows you to get a lot of initial debugging and unit testing done without hampering anyone else's progress. It may not be an option for you, but it is an option.

The concept of providing each developer with their own instance of TeamSite is clearly one way to avoid the disruptions, but as you point out there is then the issue of synchronization of code changes and, or course, the cost of licensing all those TS servers.

In trying to avoid the cost, and at least some of the synchronization issues - I'm curious whether anyone's found a reasonable solution that works with multiple developers on a single server.

This has been one of my arguments for continuing to use Perl instead of Java/CSSDK for customizations - rapid development with minimal disruption. Java/CSSDK offers performance and functionality that isn't available with Perl (without resorting to calling CLTs and thus not truly Perl)

Autonomy Interwoven has been pushing Java/CSSDK and threatening to "get rid of perl" for years now - but I've never seen anyone provide a reasonably detailed design for being able to do this without either constantly disrupting the single DEV server or spending millions more $'s to buy every developer their own licensed TS server (which, of course, Autonomy Interwoven would be more than happy to sell to them ;-)

Adam Stoller

I suppose it is either multiple vm's or junit. But junit is not the same as "the real thing".

Pardon my ignorance - but how would junit assist in this issue?

RonaldV

Well,

junit can be used to run and test the java code stand-alone, on the developers pc that is; before pushing it to the teamsite machine for the final test-run. That way you are somewhat sure that what you push to the server will (more or less) work.

By the way, I assume that when you develop java code with more then, say, 2 developer, you use a source-code-version like cvs, subversion, etc. With this the flow would then be:
1. local testing with junit
2. check code into cvs
3. automated nightly builds & deploys to teamsite
4. final real live testing.
[but giving each developer his own vm is faster/better]

Now, who says that java beats perl?

Adam Stoller

Well,

junit can be used to run and test the java code stand-alone, on the developers pc that is; before pushing it to the teamsite machine for the final test-run. That way you are somewhat sure that what you push to the server will (more or less) work.

Let's run with this mini-thread here for a bit.
If I have junit running on my client machine, presumably I'd have to bring over all the CSSDK jar files and such in order to be able to compile and run my code - right?
- What about the code that needs to interact with TeamSite (CSUser objects, CSGroup objects, CSUrlExternalTask objects, etc.) - would that be able to run on my client machine in this setup?
If not, all I can do on my client machine is make sure that the code is written according to the jar files (which I can do in something like eclipse), but the only code I could really test would be basic algorithms - which kind of defeats the purpose. Or am I misunderstanding how I would get this to work correctly from my client machine with a remote TS server?

RonaldV

We are diving into the deeper water of junit now, and I am no junit expert.

Having said this....

1. yes, to compile in eclipse you will need the jars on your local machine. With a bigger team you could set up maven for this.

2. junit is used to test a class (f.i. a servlet). With junit you prepare some input for the class, call the class with this input and compare the result of the execution with an expected result.

Now, if you class/servlet uses some backend stuff (cssdk, database, ....) you can use jmock, to mock the execution of this backend. It is like saying, if the code calls dbhandle.execute() you should return result xyz. How one would set this up properly with cssdk is beyond me. At first glance is sound quite complex to 'mock' all code that does, say getcsclient(), getCsFile(), setExtAttr(), in this order.....

Maybe some junit/jmock-guru could say something about this.....

Hope this helps.

Migrateduser

If you're making an argument of using Java vs. Perl, by using all the above voodoo just to be able to validate your logic, that is not a very good argument. It is so overcomplicated, that I would think the multiple toolkit approach seems reasonable after all that.

I don't have my own VM - I am doing Java development the way Ghoti initially described it. Multiple developers on a single TS server, using TeamSite to version our code (no SVN or CVS - we are eating our own dog food here). A very small group of consultants with laptops use the VM approach, but still a few of us are not able to use a VM. So we have a branch in TS for our code development, then we each have our own workareas in that branch. We are careful not to step on each other's toes and make sure we have an up-to-date codebase in our own workarea before running a toolkit. It is disruptive and when multiple projects are being worked on at the same time, it definitely hampers progress.

When it comes time to deploy bug fixes, enhancements, and new development into our QA/Prod environments, it requires another level of care. I create a sub-branch off the code "trunk" and initialize it with the current production codebase, then copy only the code that has changed for the updates we are going to deploy (as multiple projects may still be in development). We also may have a different codebase in QA than is in Production, so I need to keep track of both in separate sub-branches. It can get complicated. Add to that the fact that some people are working off their own VMs and need to both update their codebase and ensure that they also update ours, I can see where Ghoti would want a better solution.

RonaldV

If you're making an argument of using Java vs. Perl

Why do you say this?

Migrateduser

Now, who says that java beats perl?

Because you said this.

Adam Stoller

If you're making an argument of using Java vs. Perl
Why do you say this?

Please - let's not get into the whole Java vs. Perl debate right now - there have been other threads regarding that.

Let's just assume - for the context of this thread - that there has been a decision made (rightly or wrongly) to use Java / CSSDK for development of customizations for TeamSite.

The issue is how to do so in a reasonable, non-disruptive (or minimally-disruptive) manner if you have multiple developers working on the same DEV box (we'll assume that there is a DEV box that is distinct from a PROD box)

Thus far, the junit/jmock approach seems to be overly complex without providing a real good verification of the code being developed (it seems to rely on someone spending quite a lot of time trying to make a system that pretends to be TeamSite so that it can return some semi-reasonable responses without actually being TeamSite, so you cannot really verify the code does what its supposed to do in changing situations / scenarios)

I also find it interesting that nobody from Autonomy Interwoven has entered this thread to present some form of solution. Does that mean they don't have a good answer for this either? They haven't seen the thread? or they don't provide this information without paying for their services? (I'll be nice and assume it is not the last one)

So far - we either have a complex "mock" environment being setup, or a complex and potentially costly environment where each developer has their own DEV server and needs to synchronize their code with each other before actually putting it into place on the "real" DEV server.

Any other ideas from experience?

Adam Stoller

If you're making an argument of using Java vs. Perl
Why do you say this?

Now, who says that java beats perl?
Because you said this.

Actually, if you read that as written, I believe the statement is Perl-biased not Java-biased - so there was no argument being given for using Java vs Perl, if anything just the opposite.

Please - stop the mini-thead - and concentrate on the actual topic at hand.

RonaldV

I also find it interesting that nobody from Autonomy Interwoven has entered this thread to present some form of solution. Does that mean they don't have a good answer for this either? They haven't seen the thread? or they don't provide this information without paying for their services? (I'll be nice and assume it is not the last one)

Well Iwov, you have had over 2 weeks to think about this?!?

Shivangi Malot

Thanks Ghoti for putting this forward. This is a very good & relevant question to the current devlopment structure & i am sure many teams are facing this.

One of the way could be to excute hourly or bi-hourly builds with the help of Hudson tool for continous integration.

- Configuring Hudson to run Make toolkit Every Hour/2-hours, it builds jar from svn & places to customer src
- Hudson sends a mail to every dev 5 min prior to the maketoolkit
- Developers to finish check in their code 5 min prior to the hourly build.
(also, any experienced dev within the team helps a lot w.r.t cssdk dev)

This approach would definately consume time but than it formulates the dev & build process.

Other disads of using Java based approach is running maketoolkit builds complete application & any build failure would mean disrupting the complete ccpro application making it tough to debug.

I hope above looks meaningful.

Adam Stoller

One of the way could be to excute hourly or bi-hourly builds with the help of Hudson tool for continous integration.

- Configuring Hudson to run Make toolkit Every Hour/2-hours, it builds jar from svn & places to customer src
- Hudson sends a mail to every dev 5 min prior to the maketoolkit
- Developers to finish check in their code 5 min prior to the hourly build.
(also, any experienced dev within the team helps a lot w.r.t cssdk dev)

This approach would definately consume time but than it formulates the dev & build process.

The hourly or bi-hourly automated build approach ("fire in the hole") might work (if nothing has changed, then nothing gets built; if nothing gets built, nothing gets deployed; if nothing gets deployed, there is no server disruption) - however the frequency or infrequency of the automated builds becomes a bit of a problem as it will invariably be too frequent for some folks and not frequent enough for others - or to put it another way:

per "release" - such that any fundamental errors in the code can be fixed quickly and all code can be tested "rapidly" - without one developer's work necessarily interfering with another developer's work.While I appreciate the thought, I don't think your proposal really meets that criteria.

RajatChopra

with the ts build process, it usually takes longer to stop all the services, build the code, start all the services.

a solution we've found to be helpful is to have a standard java project and package that as a jar file.

this jar file is dropped into application container / iw-cc.war / web-inf / lib and jboss is restarted.

this usually takes us roughly 2 minutes of downtime from stopping jboss copying the compiled code jar file and starting it back up

code is compiled outside of ts within an external setup such as maven.

a teamsite build is done only once a week. mostly it is just jboss re-boots.

moreover, this methodology is adopted only for workflow/teamsite work. none of the livesite work is tested in ts, till it is properly tested in lsds. only after that do we deploy into ts for a ts build.

but again, we use the concept of a external jar in the lib as code packet.

hope that helps.

-Rajat

Adam Stoller

This sounds a bit more promising - can you provide a bit more information about maven and how you would bottle up all of the development work from various developers outside of TS in such a way that one developer's work doesn't get removed by another developer's work?

It sounds like it is an SCM system of sources (version management + build management). Is this something that would have a repository sitting on a server and client installations on the individual developer's machines?

Although it would introduce another "system" into the works, it might be a reasonable approach - although you still have the 2-minute disruption for each developer's changes such that having 10 developers working at the same time on different projects could still cause significant periods of disruption as they test out their code and continue tweaking it - but it does sound better than trying to do it all with make_toolkit.ipl.

Any more information you can provide on the setup, and caveats, etc. would be appreciated.

chandu1987

Hi Guys,

We too suffering with this problem for many days.As the people posted different solutions for this issue agian it will take same time as you run build.sh or copy external jar and restart jboss application server.

But one thing we customized in our dev environment is we written Ant script to compile and create jar file for project source files (placed in customized folder for each specific project in iw-home) and deploy to iw-cc.war lib folder and restarts the jboss.

I am started working on this for good solution atlease for dev environments and will post the same if my hardwork or luck favours me...........

thatfish

The following approach I cannot confirm is supported or advised and requires a slight shift in mindset although it worked for us on 672 ...

We have used some of the above CI principles (CSSDK, maven, SVN, mokito and hudson, etc) given in this thread. By adapting to a "teamsite application approach" we've been able to develop in much the same way as any Java Dev team develops applications with minimal impact to the wider team and environment.

Mindset change :- Much in the way that iw-preview, iw-cc, iw-rta are applications to tomcat create your own application.

Create your TeamSite code for a particular project into a separate package i.e. a war file and deploy them onto the tomcat application as you would any java app.

Then by configuring tomcat correctly you can reload your app on-the-fly and ultimately integrate your code cleanly with your dev team.

Simple HOWTO and I hope I have given all the steps:-
Firstly setup the main tomcat application so you can get to the manager interface:-
./servletd/conf/tomcat-users.xml

You should be able to access the following url:-
http://teamsitedev:8080/manager/html
I do not advise enabling this in production.

Edit /app/iw-home/servletd/conf/server.xml.template
and add/update the following line at the bottom of the file to include your "teamsite app", below the last Context element but within the Host element:

 
e.g.
Context path="/teamsite-dependency-mangement" docBase="/opt/app/iw-home/httpd/webapps/teamsite-dependency-mangement-1.0-SNAPSHOT.war" reloadable="true"

NOTE:- reloadable=true

Deploy your app to teamsite :-
e.g. /iw-home/httpd/teamsite-dependency-mangement-1.0-SNAPSHOT.war

Update tomcat so the application is recognised:-
/app/iw-home/iw-webd/conf/rewrite.conf.template


RewriteCond %{REQUEST_URI}   ^/(teamsite-dependency-mangement)(/.*)?$
    RewriteRule .   \
http://__IWSERVLET_HOST__lithium_IWSERVLET_PORT__%{REQUEST_URI} [P,NE]

You'll need an iwreset -ui here as a one off task.

So, every time you deploy your app (/iw-home/httpd/teamsite-dependency-mangement-1.0-SNAPSHOT.war) go to the the tomcat manager app click "reload" and your new code is deployed.

This is a pretty heavy-weight approach and did take a lot of effort to setup and will have some limitations. However, now anyone in the team can update the code and deliver to the dev server without requiring a reset or downtime to the dev environment.