I have the following scenario wherein there is a property file with some values for different variables and these variables should be configurable for different environments. When I build the project, I have to build it for a particular environment (say test). The package is deployed to test and the testers certify that the package is production ready. Now when we have to move the files to production, the testers would like to move the package that is already tested and not interested to build a new package for production. Of course there are many ways to do that using maven profiles and svn tag. But is there a better solution to this?
Effectively what I want to achieve is What I Test Is What I Want In Production. Unfortunately with Maven profiles, I can build the artifacts targeted for different environments. With this notion, I have built an artifact for test environment, the QA certifies the package and now I cannot move this QA certified package to Production as I have to modify the property files to point to Production environemnt. This being the case, I have to do a fresh build. I was thinking of ways to avoid this. One possibility is to externalize property files. Move the property files located under the project's src/main/resources to the server. Is there a much elegant way of doing this?
In our environment, test builds are used only by the developers. Anything that goes to QA is always built using the production profile.
Exactly what is the difference between your testing and production profile? For us, the difference is only properties and configuration file entries. Most of them are in a config directory, but there is one inside a WAR file. But when the WAR is deployed to Tomcat, it is automatically exploded and thus we can get at the file if we need to. But, our QA environment matches our production environment exactly, even down to the machine names and addresses. Thus there are no changes needed in QA.
The difference is in the database configurations in the property file. This property file is located inside the packaged war. When the build is made, it is done for the QA environment. This build contains the database connection details for QA database. The QA certifies this package. Now, when it is time to move the files to production, we have to make another build so that the property file reflects the connection details to production. This is exactly what I want to avoid.
I use one build for all environments - desktop, QA, production. That way I know that the same code is executing - and being debugged - regardless of where it is deployed.
To get around such annoyances as which database to connect to, I inject environmental data from external sources. For simple things, such as database connections, using Tomcat as the server, that is done via Tomcat Context definitions. And by the way, it sounds like you are not using server-supplied database connection pools and are instead probably using direct JDBC connections in webapps, and that is inefficient.
The Tomcat Context is good for server-created resources such as connection pools, and when you have a relatively small number of options to override. Occasionally, however, I run into projects which are have too many options for me to want to maintain that way, since reading such values requires JDNI code in the application, and sometimes a simple Properties object is better. For cases like that, I use the Context to point to an external Properties file location, use JNDI to get the file path, and then open, read, and load the Properties in the usual way.
Customer surveys are for companies who didn't pay proper attention to begin with.
I had to reverse-translate that, and even then I'm not precise on what "working without friction" should mean, but assuming it's ohne Reibung and I take a poetic interpretation of "without disharmony", or "without conflict", then that's a reasonable translation.
In any event, I deploy the exact same binary WAR, without change, to all my servers. All of the server-dependent information comes from external sources.