Question

I’m not so experienced but i worked on some big Java EE projects (using maven2) with very distinct ways to handle the installation / delivery on the different platforms.

1) One of them was to use snapshots for development and then make a maven release, of components and main webapplications. Thus the delivery is:

• war/ear files
• List item
• properties files
• sgdb files
• some others

And teams will use that files to put the new application versions in the different platforms.
I think this process is strict and permits you to always keep easily the different configurations passed in production, but it’s not really flexible, the process is a bit heavy and it conducted us to sometimes do some dirty things like overriding a class of a war to patch a regression…
This is an e-commerce website with 10million unique visitors per month and a 99.89% availability.

2) Another i saw is to checkout the sources on each platform and then install the snapshot artifacts in a local repository. Then the application server will use these snapshots of the .m2 folder.
There is not a real delivery process since to put a new version in production, we just have to update the sources of the components / webapps, do some maven clean install and restart the application server.
I think it’s more flexible but i see some drawbacks and this approach seems dangerous for me.
This website has a frontoffice, i don’t know the numbers but it’s far less than the 1st one. It also has a big backoffice available for most employees of a 130 000 people company.

I guess depending on the website, its exposition to the public and the availability required, we have to adapt the delivery strategy to the needs.

I’m not here to ask which solution is the best but wonder if you have seen different things, and which strategy you would use in which case?

Answer 1

Without dealing dealing web sites, I had to participate in release management process for various big (Java) projects in heterogeneous environment:

• development on “PC”, meaning in our case Windows — sadly still Windows Xp for now — (and unit testing)
• continuous integration and system testing on linux (because they are cheaper to setup)
• pre-production and production on Solaris (Sun Fire for instance)

The common method I saw was:

• binary dependency (each project uses the binaries produced by the other project, not their sources)
• no recompilation for integration testing (the jars produced on PC are directly used on linux farms)
• full recompilation on pre-production (meaning the binary stored on the Maven repo), at least to make sure that everything is recompiled with the same JDK and the sale options.
• no VCS (Version Control System, like SVN, Perforce, Git, Mercurial, …) on a production system: everything is deployed from pre-prod through rsynch.

---

So the various parameters to take into account for a release management process is:

• when you develop your project, do you depend directly on the sources or the binaries of the other projects?
• where do you store your setting values?
  Do you parametrize them and, if yes, when do you replace the variables by their final values (only at startup, or also during runtime?)
• do you recompile everything on the final (pre-production) system?
• How do you access/copy/deploy on your production system?
• How do you stop/restart/patch your applications?

(and this is not an exhaustive list.
Depending on the nature of the application release, other concerns will have to be addressed)