Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I intuitively think that an application should be exactly the same in DEV, QA, and PROD environments. However, I have been asked to add a feature to an application that will only be available in DEV environment.

I have a server and database for each environment - dev, test, and production. I want to know if there would be any possible issues that could arise (and "best practice" for avoiding them) from having a feature of a large application only available on development server.

The tool modifies DEV database values and produces an output script that will be tested in QA and afterwards will be used to modify production data. The authentication that allows access to the feature will not be available in QA and PROD environments. I understand that this will work, but is this correct for Java EE standards?

The feature would:

  • Modify values in the development database then export a SQL script that has the current state of the development database.
  • The SQL script would then be run on testing database and if every function worked properly afterwards it would also be run on production database.
  • The code that would modify the testing and production databases is not available in either of those environments.
share|improve this question

closed as unclear what you're asking by gnat, GrandmasterB, Robert Harvey, GlenH7, Dynamic Dec 19 '13 at 0:45

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

What environment is it? Java EE? Java SE? C#? Some thing perl, python, or ruby like? There are different approaches for each of these. – MichaelT Dec 18 '13 at 16:01
recommended reading: Why is asking a question on “best practice” a bad thing? – gnat Dec 18 '13 at 16:54
@MichaelT, It is Java EE. – Andrew Campbell Dec 18 '13 at 17:34

There is the best practice of "dev code never makes it into production". There is also the best practice of "all builds are the same". Unfortunately, these two can make for some difficult decisions and compromises between the two best practices.

If you have to compromise them, the all builds being the same is probably the better best practice. In part because it means you can pull a production build into the dev environment, flip the appropriate switches and be able to investigate the internals with the dev tools available.

One example of this is how logging works. LOG.debug("foo"); only runs in the environments where the debug configuration for logging has been enabled - which isn't production.

Within Java EE, one of the settings available is that of the server/vm settings. With Java, you can use the -D option on the vm to set certain properties that can be queried at runtime with System.getProperty("propname");

With this approach, one could change the VM options to have -Djmoreno.debug which means its running in a dev enviroment.

This can also be put to good use when you have multiple machines in production that need properties (for example file paths)... and you want to only deploy one copy to both - change the option so that each vm knows its file path and then your code remains consistent between the two production deployments.

Its not so much a 'best practice' issue, but rather an inevitable design to avoid bad practices.

For the specific case of "here is functionality that only exists in dev" with a JEE environment - I would encourage looking into a dbfiddle.war file that gets bundled into the development .ear - it doesn't make its way into other .ear files. This way the separation of development functionality from other functionality is clear and distinct - it can't accidentally leak into other environments with a misconfigured bit of code or server setting (misconfigured build - yes, but that is easier to check - just open up the .ear and look).

The other thing that (if this doesn't need to be bundled into the .ear) would be just write a stand alone application - don't even deploy it to the server. Just run it. Ideally, any business logic that it needs is properly separated into a .jar that both the stand alone and the JEE code can use (rather than having it tightly coupled into the JEE code).

share|improve this answer

While I agree that you want all three to be as close as reasonably possible, there are frequently situations where it is unreasonable to make them identical.

Whether this is one or not, I of course can't know -- but it doesn't sound like it. Nothing you've said, indicates that you can't create a seperate utility to make whatever changes are necessary and create your script. Which is what I would suggest doing when you have a feature that is only used in dev (instead of the more common scenario of having a feature that needs to act slightly different in dev).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.