I would like to hear the opinion of folks here on how they would solve the following problem in their environment, when multiple developers collaborate on the same ear file.

I work on a team of 5 developers. We all contribute small pieces to a web app (myApplication.EAR), which is built and deployed onto the same WebSphere Application Server Server. (A single deployment system shared by the whole team).

After the application has been deployed, we can all access it through a URL (http://hostname:8080/helloworld) and perform our test.
However, if developer1 finds a problem in his component on the EAR, he/she would like to fix the problem, rebuild the EAR and redeploy it. Unfortunately, he/she has to wait until the other developers are done, so he can rebuild and redeploy without interfering with the other developers.

Question: In an environment that shares the same deployment system, is it possible to deploy the same ear file and have it accessible in different ways by different people? I believe each developer could change the contextroot and each can then deploy a different ear onto the same application Server. Is that accurate? Are there other options you can think of, if we all want to share the same deployment system?
We are trying to avoid a situation, where we need to have as many deployment systems as there are ear files.
Thanks for your input.

bepanda,

As you called out, you can deploy an instance of the EAR as many times as you'd like provided that they are unique in Name (application naming) and context root.  Keep in mind that any shared resources (JDBC, Datasources, etc.) would likely be shared in this scenario.  Additionally, should there be a problem in the JVM itself because of the code in one of the applications, it becomes very hard to diagnose.

Alternatively, you could have a sepperate JVM for each application developer to test their code and then a single JVM for your UAT of the built EAR.

I recommend that you look into IBM's WebSphere Application Server for Developers edition (www-01.ibm.com/software/webservers/appse...).  This could allow your developers to run a local instance of WAS Base on their desktops for their testing and development.  Unless something has changed recently, this developer edition is free of charge.)

Regards,
Erik

Eric

WebSphere developer edition is a great point .

regarding renaming the application and deploying on different context ... what i observed is that in a network deployment environment, simply renaming the WAR/EAR file is not enough but we need to make the name change at web.xml level and then we can deploy with different context root. 

One extra question, your application use EJB3?  because when I worked with ejb's we needed changed name for jndi references to ejb too

bepanda,

The quick answer, as others pointed out, is: yes, you can. You'll have to go through a careful survey of all the resources being used by your application - and that might need to be replicated across the many installations. Depending on the size of your project, and the number of resources, that can be a bit of an annoyance and time-consuming, but the good news is that you do that once, and as long as you don't change that resource set that much, youŕe likely to be ok with that.

In my experience, though, the big challenge here is the human factor, not the technical one. Developers tend ot be very lazy and too self-confident, which can be a good thing in many situations, but it comes to lousy results in system administration.

I have been a WAS admin in a company where they did exactly that what you are asking. Every now and then they would come in despair because "nothing was working, this websphere server is a crap", only for me to find out they had deployed one version over another, or someone had forgotten to change one context root or some other configuration.

If you don't have solid build AND deployment procedures, I would say you are asking for trouble. If any of these installation-specific settings is manually set upon deployment, one day someone will forget - because he/she is in a hurry because of the deadline which will cost zillions of dollars, and will screw things up and blow the deadline and the money in one blow. Believe me, I've seen it happen.

There are other potential pain points here:

- developers usually move from one sub-team to another quite easily, after a while it's quite easy to have a developer wasting lots of time because he/she is using the wrong URL here or there - after switching the URL a dozen of times, it's not a hard thing to happen.
- depending on your application interfaces, and I am thinking web-services here, ou might have to replicate the multiple isntances in other systems to be able to effectively test the application
- if you don't have a solid branch-policy in your SCM repository, it's also easy to have one team stepping over the other(s) team(s) toes
- some developers use customized settings in their own developing environment, because they feel more comfortable with them. That's ok, but sometimes this may lead to situations where one's environment is not suitable for testing the whole application. Thus, you should not fully trust any of the developers' environemnt for testing purposes, thus, I'd recommend an additional installation, one in which the application is pulled from the lastest commit in version control, built and deployed, without any human intervention. Then you can test integration among the different development branches.

To name a few. Naturally, your mileage may vary. If you have a highly disciplined team of developers, you can scratch most of what I wrote. Just my $0.02.

Cheers,
Alexei 

Thanks all for you answers and suggestions.
Alexei, what you are poiting out is exactly what has me worried: The fact that developers might not be careful, when setting up parameters to deploy.
We will try to use a very strict procedure to get around this.
Basically, what I had to do is create as many virtual hosts as I need instances of the Enterprise Application.
I deployed each EAR into its own virtual host, and things worked like a charm.