Question

We are currently using JDeveloper to build our production EARs. One problem with this is that if the developer doesn’t add new files to a VCS, then that developer is the only one capable of making EARS, and therefore he can use unversioned files as well.

What would be a good system that seperates this, so that EAR files can be correctly produced without depending on the local developers workspace (this would also ensure that they add their files to a VCS before allowing to make a deployment/check-in).

Answer 1

One problem with this is that if the developer doesn’t add new files to a VCS, then that developer is the only one capable of making EARS,

If the developer doesn’t use the VCS, this is not your only problem:

• You cannot reproduce things in another environment, you’re tied to the developer machine (but you’re aware of that). What if he is sick?
• Not versioning files means you don’t have any history of modifications and that you don’t know what you put into production (“Hmm, what is in this version? Wait, let’s open the EAR to check that.”).
• And last but not least, in case of hardware failure (e.g. a hard drive crash), you can say good bye to everything that is not in the VCS.

So, the first thing to fix is to ALWAYS version files, even if there is only one developer as working alone doesn’t save you from the mentioned problems. These points should be reminded (the developer needs to be aware of them to understand their importance).

To make sure this happens, you should actually not rely on the developer machine to build the EAR but rather rely on an “external” process that would be the reference. You want to avoid this syndrome:

alt text http://img716.imageshack.us/img716/9901/worksonmymachinestarbur.png

To put such a process in place, you need to automate the build (i.e. your whole build can be run in one command) and to break the dependency with your IDE. In other words, do not use the IDE to build your EAR but rather use a tool like Maven or Ant (which are IDE agnostic). That would be the second thing to fix.

Once you’ll have automated your build process, you could go one step further and run it continuously: this is called Continuous Integration (CI) and allows to get frequent, ideally immediate, feedback about changes (to avoid big bang integration problems). That would be the third thing to fix.

Given your actual toolset (which is far from ideal, there is not much community support for the tools you are using), my recommendation would be to use Ant (or Maven if you have some knowledge of it) for the build and Hudson for the continuous integration (because it’s extremely easy to install and to use, and it has a Dimensions plugin).