3

After much time and effort, we're finally using maven to manage our application lifecycle for development. We still unfortunately use ANT to build an EAR before deploying to Test / QA / Staging.

While we made that leap forward, developers are still free to do as they please for testing their code. One issue that we have is half our team is using Tomcat to test on and the other half is using Jetty. I prefer Jetty slightly over Tomcat, but regardless we using WAS for all the other environments.

Should we develop on the same application server we're deploying to?

We've had numerous bugs come up from these differences in environments. Tomcat, Jetty, and WAS are different under the hood. My opinion is that we all should develop on what we're deploying to production with so we don't have the problem of well, it worked fine on my machine. While I prefer Jetty, I just assume we all work on the same environment even if it means deploying to WAS which is slow and cumbersome.

What are your team dynamics like? Our lead developers stepped down from the team and development has been a free for all since then.

Improve this question

6 Answers 6

Reset to default
5

My question is, should we develop on the same application server we're deploying to?

Not exactly the same server. You can't test upgrades and new releases if you make the silly rule that all servers are identical. [Some folks try to pass the rule. It can't work because it prevents upgrades or creates a special case that isn't all that special and happens so often the rule is rapidly seen as dumb.]

However, your situation of multiple servers -- not just multiple versions -- is dangerous.

You should have the same technology stack. You can have different versions. But not different products.

However, developers will often have newer versions than what's in production. That's how changes march down the pipeline into staging (and eventually) production.

The hard part is achieving a consensus on what's the right thing. If some folks simply refuse to cooperate, it's time for their managers to find new things for them to do.

Improve this answer
1
  • I agree, as developers, we often want to try the latest stuff, but getting that into production will take a little bit longer.
    – Walter White
    Mar 24, 2010 at 20:09
2

You need an integration server similar to the production server.

IMHO it is important for developers to develop in what they want (e.g. I develop localhost with Tomcat because its fast, good luck with doing 10 deployments a day with WAS...). But after development is over, stage up an integration server and test your app there. This should be as similar as possible to the production server.

If you can afford it have more than one environment (e.g. we once tested on 4 types of servers).

Improve this answer
2
  • 1
    I agree that tomcat is fast, but developing on different environments leads to ongoing problems. If your target platform is X, it is a waste of time to test on others. I don't like WAS either. If we can accomplish everything with Tomcat or Jetty, we should evaluate why we're using WAS in production.
    – Walter White
    Mar 24, 2010 at 20:07
  • If you have a product for different customers then it makes sense to have more environments to test on. I get that this is not your case. But consider that we use tools that make our job easier. Before imposing a certain development environment, consider how it will affect your developers. If people will have it harder to do their job you will lose other people, not just your lead developers.
    – user7197
    Mar 25, 2010 at 8:23
2

I think what you want is quite sensible. If your application will only run on one type of server, then it makes sense to mimic the configuration of that server so that you know right away during development if something will or will not work. There is no sense in letting bugs due to different environments accumulate.

Another alternative is to use a continuous integration tool, so that developers know right away whether it will work on the deployment server, but they can use whatever environment is most productive for them.

Improve this answer
1
  • +1 for the CI server. Developers need quick turnaround time, but you want to get bugs before they get to production. Setting up a CI server to build every hour, then deploy and run the tests using the production target should be a slam-dunk.
    – TMN
    Feb 8, 2011 at 20:40
2

The closer to production the more the servers should be identical. The purpose of that is to make sure the final installation will be free of unanticipated problems, i.e. the "works for me" syndrome. However, the closer to development, we need more freedom to experiment. So I would say that the entire set of platforms don't need to be identical, and in fact really can't be.

One of the things you are doing right is using an automated build script. Whether it's ANT or Maven isn't as important as the fact that the application is compiled and the JARs are assembled the same way every time. This will help avoid a number of issues.

The pain point you mentioned--bugs due to differences in application servers--is a double-edged sword. The more application servers your app is exposed to, the more portable it will be once you've ironed out the problems. On the other hand, unless you are building an application that your customers will be free to install on their own app servers the extra work needed for portability just eats up time that you could spend fixing other, arguably more important, bugs.

It's a sad fact of life that sometimes our choice of application server is constrained by our client's IT policies. "Thou shalt use IBM or Oracle, yea and verily" If that is the case, then at least everything from the test server on should be using the same application server as production. In development land, you may want to standardize on only one of the alternative application servers. If you are moving to Maven (as it sounds like you are), then Jetty is a natural match. Maven has a preference for Jetty, so running the application in the app server is as simple as typing mvn jetty:run (see this article).

Essentially, you'll want to minimize the number of things that can go wrong. If you can catch the majority of the incompatibility issues at the test stage, you are way ahead of the game. Staging should be pretty much lock step with production, as it is going to be your last chance at finding install problems that might bite you in production. The same hardening processes you have to use in production should also be used on staging. Testing should use the same technology stack that will be used on both staging and production, but does not need to be kept in lock step. It will be your first opportunity to find problems due to upgrading the server or libraries you are using.

Improve this answer
1

Regarding Websphere, if licensing issues prevent developers from using it also for development the best alternative (compared to JBoss etc.) is perhaps Websphere Community Edition. Even though it has a different code base than regular WAS, IBM is trying hard to make it as compatible as possible to persuade developers to use it instead of other application servers.

Improve this answer
1
  • Na, it isn't licensing, it is turnaround time. We can start our 'watered-down' application in Jetty in < 30 seconds and redeploy in seconds. On WAS, that takes minutes, and sometimes we have caching issues. As much as I dislike WAS (which is a lot), I think it is better to test and develop on what you're deploying to in production. If we have issues with WAS, then we should evaluate whether or not WAS should be used in production. If we cannot change that, then perhaps, we need to work with IBM to get WAS deployments fixed so we can test faster with fewer problems.
    – Walter White
    May 11, 2010 at 13:24
1

I think all those environments should be as close as possible. I've been bit by bugs which happened on Tomcat (testing) but not on Jetty (dev). While we caught them before going live, it would have been far easier to catch them earlier during development.

Even worse, some bugs only occurred on the dev's computer, but not on testing (which is closer to production), making us waste time on irrelevant problems.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.