I want to be able to build a war file and deploy it in multiple environments. I know I can create an ant task to get the environment and either include the files in the war, or replace the tokens as necessary. However, this would lead to as many different war files as environments (dev, QA, DR, prod, etc…). It seems that this would create say a production war file that has never been tested. Yes, only the environment specific properties should change, but there’s no way to just deploy that war file in dev if there are issues.
Is there an easy way to create one war file and make all of the config files external? Should I set there location in the startup.sh script? This would seem to require code changes to get the files from that external location, and I’m not sure how this would work with some framework specific items, like the database config. Currently, I create one war file with the dev config, then I deploy it to each environment so it gets exploded, then I run a script to copy the environment specific properties files, then restart tomcat so these properties take effect, but this doesn’t seem like a good solution.
The properties files I need are the database configuration, application specific properties like location of the mail server, and the log4j.properties.
I’m deploying these on Linux servers running Tomcat and I have full access to the servers, so I can create any ant, bash, etc. scripts that I need.
In general I think it is ‘normal’ practice to create a war/ear for each environment. I don’t agree with your statement that you are ‘deploying a war file that’s never been tested’. You are deploying a war file where the configuration hasn’t been tested is more accurate. Maybe you can write some unit tests that verify the production configurations and run them when you build your prod war so you can check off your ‘test prod war’ requirement…