Should Development / Testing / QA / Staging environments be similar?

Question

Hi all,

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.

My question is, 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.

My question is, 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.

Walter

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.