This article presents three brief use cases that examine the ways that JavaEE applications are moved across environments. We also show you how a new philosophy could be applied to these use cases to minimize errors, increase deployment speed, and assist in troubleshooting applications.

A New Philosophy, A New Approach
The new philosophy encapsulates the way sys admins should think about deployments. Today, deployments are most often thought of as atomic instances, as actions, rather than a process. A new approach is to think of deployments holistically. For example, deploying EAR files should not be parsed apart from configuring a server. The method for deploying to the test instance shouldn't be any different than the method used in staging, production, or development. Furthermore, troubleshooting a configuration is just as much a part of deployment as any other step. At the end of the day, all of the pieces need to be considered together to make the application work the way it was intended. In short, deployments are dynamic because they go through a growing, changing, and unpredictable lifecycle. The professionals who manage application environments are forced to make assumptions about their use and growth; for the most part those assumptions are usually correct. But over time, those environments will invariably change in unexpected ways: new technologies are adopted; business requirements change; even the personal style and best practices of the IT professionals managing the process may evolve. All of these issues make the application environments highly variable. Each deployment into an environment can be quite different, presenting many problems unless the deployment process is flexible enough to adapt to those differences. Deployments are inherently dynamic because each environment may differ slightly from every other environment, and the environments themselves may be in flux. Also, keep in mind that many companies today may be developed in one environment and deployed in another (e.g., develop on JBoss then deploy on WebSphere). The new way of thinking provides an opportunity to conceptualize the deployment process and approach.

An effective Java EE deployment process must be able to:

• Baseline a "known good" configuration environment.
• Understand what changes will be made if that configuration were applied to another environment.
• Apply only those changes that are required and provide a point of control for "optional" configuration changes.
• Provide robust error management including rollbacks, uninstalls, logging (for debugging), and troubleshooting.
• Be able to drop seamlessly into an existing application lifecycle process.
• Provide extension points for other configuration parameters and be flexible enough to deploy to the environments needed without undue reliance on infrastructure.
• Provide an audit trail for changes and monitor the application to verify that it continues to be configured in the way the business wants.

• Payload (the What) - the bundled application binaries (EARs, WARs, etc.) and the desired configuration (JDBC, JMS, etc.). The configuration should be abstracted from and independent of any target specifics (such as topology, application server vendor, and version).
• Target (the Where) - environment-specific details (hostname, db location, cluster size, etc.).
• Mechanism (the How) - an application or tool that can deploy any element in a payload to any given target, and also generate payloads from a target.

The following are brief examples of specific use cases that demonstrate the value of this approach. While not inclusive of all of the benefits, these examples present concrete reasons for adopting this philosophy.

Use Case 1: Modeling an Existing Application Infrastructure
This use case is most common at the beginning of a deployment - a simple baseline to determine what does or doesn't exist on the server, either as an inventory exercise or in preparation for a deployment change or upgrade. Doing even this simple activity with existing methods can be difficult. With most application servers there are really two ways to go about doing an inventory, and both are fairly cumbersome. The first is to page through the management console and note the applications installed, how they are configured, and what other configurations are present (JMS, etc.). A second way involves parsing the raw configuration files from the server to discover the required information. Neither approach is simple; both feature multiple opportunities for error even if done by experienced staff.

The new approach transforms the modeling task into a straightforward procedure. The mechanism defined in this approach can not only deploy applications and configurations, but also generate payloads from a target environment. In this use case the mechanism would be pointed at the target to generate an abstract representation of the target's configuration. This output would serve as both a model for the application infrastructure and a baseline for applying that same configuration to another environment. For example, there are tools that generate output from a server snapshot; the output could be an XML representation (human-readable) of the entire application configuration. This output is both easy to generate (because the mechanism is doing all the work for you) and not subject to error. Furthermore, the XML representation is an extremely portable semantic representation of the configuration. In other words, technical personnel can use a text editor (any text editor, really) to read the contents, or feed the contents of the file to any process to transform the captured semantics into some other output, be it an HTML rendering or a set of instructions.

Use Case 2: Migrating Applications from Development to Quality Assurance (QA) to Production
Every Java EE application goes through a development/test lifecycle. Most commonly, promoting applications from environment to environment is achieved via two routes: manual or scripted deployment. In my experience either route is problematic. Manual deployment isn't only time-consuming, but also extremely error-prone. The scripted approach doesn't give much advantage, as scripts must be continually updated and kept in sync between environments. In either case, if something goes wrong during deployment the target environment can be left in an unknown "Frankenstein-like" state. With the new approach, deploying from development to QA to production is straightforward, automated, and robust. For example, let's imagine that the target environment for deployment is a two-way WebSphere cluster. Prior to deployment, the server variables would be identified and defined, most likely in a simple properties file containing all the environment variables that should change from one deployment to the next. For simplicity's sake, we'll assume that the only variables that will change from one environment to the next are: hostname, admin port, db location, and topography. In this case, the properties file would be a simple key-value pair for each of those attributes. At deployment, the payload would consist of the actual application binaries, the XML document that describes the configuration, and the server properties. These artifacts would be fed into the deployment mechanism, which would, on-the-fly, translate the environment variables and payload into the target environment. Hostname, admin port, db location, and topography are automatically merged into the generic configuration document. The deployment mechanism then interrogates the target server and only makes the changes necessary to the environment so it matches the abstract configuration (after first identifying the changes that it will make). If at any point in the deployment process something goes wrong, then all the changes are rolled back, leaving the environment exactly as it was prior to the attempted deployment. Verbose logging of the deployment aids in the identification and correction of the underlying problems.

When the process goes well and it's time to deliver the application to a "production" environment, the same mechanism and configuration document are used to deploy the application (as was used in the test deployment). The only change is to the pre-defined server properties, which should remain fairly static across time. What's tested, both application and configuration, is what gets deployed.

Use Case 3: Troubleshooting a Configuration Problem
Let's assume that there are two servers with the same applications installed on them. One works and one doesn't. This is a surprisingly common situation in installations today. Today, comparing those servers in an effort to figure out "what's different" is an arduous task. "Diffing" the raw configuration files is a daunting if not impossible task - most configuration files contain too many false positives. The only other existing method, going screen-by-screen in the management console, is so difficult that it rarely makes the list of "reasonable" approaches. The new approach recognizes that troubleshooting is part of the deployment process. Because it assumes the ability to export configurations from servers and present that information in a standard abstract format, it can now compare those configurations side-by-side and show only those differences that matter. In my experience, approximately 25% to 40% of all deployment defects are configuration-related. Able to identify a configuration error quickly, or at least rule out configuration as a potential source of the behavior, conflict resolution is faster, easier, and more specific.

Conclusion
Deploying applications on Web application servers doesn't have to be an arduous, expensive, time-intensive process. Using this new approach, organizations can separate payload, mechanism, and target and create fast, automated deployments without using scripts. Thinking of deployments in this new way can crush the chaos, once and for all.