Tomcat deployment strategy

This is a somewhat different question about Tomcat deployment. It has been covered partially by earlier questions but I would like to here from those who have actually done Tomcat deployments.

In my organization I see two types of deployment.

1. WAR deployment to Tomcat webapps dir. Tomcat is stopped, the existing WAR file is renamed, the existing app directory under webapps (appBase) is removed, the new WAR is copied in and Tomcat is restarted. The upside: deploying WARs seems to be understood by everyone. There are two downsides that I can see.

   A. if the WAR contains deployment specific information, such as DB connect info, the development environment requires some sort of version and build control to make sure the correct deployment-specific information goes into a WAR file. This could get complicated.

   B. Many steps, not difficult but each step is a potential point of error.

2. appBase points to the application file system, deployment-specific information kept elsewhere. The applications deployable file system or a WAR file is copied to a location on the Tomcat box. The appBase attribute for the application in Tomcats Servlet.xml is modified to point to the newly deployed code. Tomcat is restarted after the copy. All deployment specific config information is kept in a separate directory under [tomcat_r开发者_StackOverflow中文版oot] that is not affected by the deployment. If any changes are required the edits can be made any time and Tomcat restarted to pick up the changes. The upside: dead simple, usually only one step, at most two steps The downside: file editing on the deployment machine may be required. This is not allowed in many production environments or must be done by a sys admin not the deployment person. May cause delays, political problems and finger pointing if something goes wrong.

As I said above, I would like to hear real world experience with either method. I definitely favor the second method. I wonder what the attraction of the first is since it seems to be much more error prone.

Thanks, -=b

Here's how I do it:

In source control I have properties files for each environment. For example, production-environment.properties, qa-environment.properties, etc. All of the properties files are in the resources source directory and are included in the WAR file.

Tomcat is started with a system property that selects the environment, for example:

-Denvironment=production.

The application chooses which properties file to use at runtime based on the system property.

No special build or deploy steps are needed. One WAR file per build is used across all environments.

Another aspect of this approach is that properties in the WAR file can be overridden by system properties. This allows ops to change properties after the WAR has been deployed. Also it allows sensitive information like database passwords to be left out of source control completely.

The first approach can be managed by automating your packaging process. I usually use maven with profiles targeting different deployment environments. The build tool ensures reproducible builds and prevents you from making mistakes.

In larger shops there is usually a big chinese wall between dev and ops and the second approach is chosen. Developers are not allowed to touch production servers.

I use kwateeSDCM to automate parameter instantiation such as DB connect info and deployment on tomcat. There's an interesting blog article that talks about deploying war on multiple tomcat instances.