© Bronze Drum Consulting, Inc. 2009. All Rights Reserved.

DeployAgility™ J2EE Application Build and Deployment

Management System for IBM WebSphere®

Overview and Technical Questions and Answers

Brian Yeats McCallion

Bronze Drum Consulting, Inc.

New York, NY 10022
http://www.bronzedrum.com/deployagility
mailto:info@bronzedrum.com
© Bronze Drum Consulting, Inc. 2009. All Rights Reserved.

WebSphere Application Automated Deployment Procedures

Overview
The automated deployment process requires content and instructions from the
development team. The instructions, or the “what to do” part come in the form of two
xml files which the development team prepares and submits. The first document, often
referred to in this process as the DeploymentRequest.xml, describes the artifacts to
deploy and where to deploy them. The second document, referred to as the Deployment
Strategy file describes deployment time bindings to be made between the application and
the application server hosted application resources. More details are provided about
these two documents is later sections of this paper.

The second part major component of the deployment process, the “what to deploy” part
of the deployment is also described in the DeploymentRequest.xml. But the actual
artifacts to deploy need to be uploaded (in the test environment) by the development team
to directories designated for specific types of content. Examples of this type of content
include enterprise application archives or “ear” files, as well as jar files, properties files,
and xml files.

Building on these conventions the process then can follow the instructions in the
deployment request and locate the artifacts. Broadly speaking, each development team
has its own unique set of input/output directories and scripts for managing the build
process.

The goal of this process is to make it possible for developers to independently deploy
their applications to the test environment, while simultaneously providing a controlled
workflow that enables an application successfully deployed to the test environment to be
repeatably and easily deployed to the Quality Assurance and Production environments
through an automated process. The deployment process keeps a detailed log of all the
steps taken to complete a deployment. These logs may be kept in the development team
deployment workspace on the test server. Also, the DeploymentRequest.xml enables the
development team to standardize certain types of deployments as well as declare who
should receive email notifications regarding the success or failure of the build process.
Moreover, the logs generated by the build process can be included in the email
notifications. The clear benefits afforded by this automation and structure include
repeatable, efficient deployments as well as detailed logs for scientific analysis of any
issues that might emerge during the deployment process.

As part of the setup process for each application group/development team a set of
directories and scripts will be made available to each team. How to obtain access to the
environment, what servers to access, as well as how to setup team members is covered in
a separate document.
What inputs are required from Development team?

1. EAR file. The basic unit of deployment to a J2EE 1.3 application server such as
Wephere 5 is the enterprise archive, commonly referred to as an ear file.
2. DeploymentStrategy xml file. This file describes how to bind resources in your
application to resources in the WebSphere environment. It offers both the
Development team, the WebSpherer team, and the Systems Assurance a highly
effective language for binding application resources to application server
resources at deploy time. For example this xml file can describe how to bind an
application resource reference to a jndi resource such as a datasource or property
file at deploy time, while insulating application code from the underlying jndi
names of the resources. It can also be used to map enterprise java beans to their
jndi names. When initially configuring a new application this file will be created
by the Development team in cooperation with the WebSphere Services team.
Once the application has been configured the Development team will be
responsible for supplying and maintaining this file. In order to automatically
deploy an application to WebSphere this file is required. Some working examples
are provided in the appendices to this document. For the most part this xml file
can be created once and then maintained through minor modifications if and when
resources referenced in the application change. For many applications this will
mean updating the file infrequently. For applications that have changing
requirements this file offers a standard and effective way of binding application
references to application server resources.
3. Jar files to be deployed to a shared library. While all of the jar files may be placed
in the inputLib directory, the actual grouping of the files needs to be specified in
the DeploymentRequest.xml
4. Properties files to be deployed to a properties file directory assigned to the
application. Each file or a zip archive of the files needs to be described in the
DeploymentRequest.xml document in order for the files to be deployed to the
specified location.
5. xml files to be deployed to a directory assigned to the application. Again, each
file or a zip archive of the files needs to be described in the
DeploymentRequest.xml document in order for the files to be deployed to the
specified location.
6. DeploymentRequest.xml. This file describes the application components to
deploy as well as providing meta-data defining how and where to deploy the
components. The DeploymentRequest.xml is currently defined to describe the
following types of deployment artifacts: properties files intended for a specific
directory, jar files intended to populate or update a shared library directory, ear
files, and xml files intended for a specific directory.

How does the Development team deliver these files to the test
environment?
Each Development team will be able to ftp files into these directories in the Test
environment as well as execute the build process that will deploy an application to the

3
Test environment. Systems Assurance will deploy applications to the QA and Production
environments.

Are There Any Naming Conventions?

1. Context Root. As described above, the context root chosen for the application
provides the base from which to build additional names associated with that
application. In applications with multiple web modules and multiple context
roots, the highest level context root should be used to refer to the application as a
whole.

2. Application Name. Applications need to be named after their context root. For
example an application with the context root of bdcconnect096 would exist on the
file system as bdcconnect096.ear. In WebSphere the application name would be
bdcconnect096. Following this simple convention is critical as it enables for
streamlined automated processing, packaging, and deployment of a given
application.

What are the Standard Directories and what Artifacts Do I Place in

Them?
For each application a standard set of directories will be made available to the
Development team in the Test environment and to the Systems Assurance team in the
Quality Assurance and Production environments.

As a general rule, directories where the Development team might upload files are
prefixed with the word “input.” Directories where artifacts produced as a result of the
build process are generally prefixed with the word output.

For example for an application such as BDCAmon the directory structure would be as
follows

/webapps/deploy/bdcamon/
docs
log
backup
InputEAR
InputProperties
InputXML
InputLib
InputDeployStrategy
inputDeployRequest
outputEAR
outputDeployPackage

4
What do I do once I think I’m ready to deploy the application to the
Test environment?

Run the script processRequest.sh (located in the root of your application directory).

Once the directories have been populated just run the processRequest.sh script. This
script transforms the xml in the DeploymentRequest.xml file into a build data file that is
submitted to the IBM supplied and supported version of ANT (v1.5.4). ANT process the
build request and executes all the required tasks. At the end of the process the build will
either succeed or fail. In either case an email will go out to the list of people you
specified in your DeploymentRequest.xml notifying them of the results. A log file of the
build will accompany the email detailing the steps taken in carrying the instructions in the
DeploymentRequest.xml.

Do I have to create a new DeploymentRequest.xml for every

deployment?
You might keep standard deployment requests on your local file system, source code
repository, or flash drive for that matter. Most deployments will fall into a normal
distribution and you will probably quickly find that a few DeploymentRequest.xml files
cover most of your day-to day-deployments. However, as of the current release only one
DeploymentRequest.xml file can inhabit the inputDeployment directory at a time. The
DeploymentRequest.xml will be packaged when the application is packaged for
deployment to QA. In the Test environment the file will remain in the inputDeployment
directory until it is removed or replaced.

How do I notify the Systems Assurance team when an application is

ready for deployment to the Quality Assurance environment?

Run the script promoteApplication.sh

This script performs the following actions
1. Sends an email to the Systems Assurance team
2. Sends an email to the WebSphere Services team
3. Notifies the list of people in the DeploymentRequest.xml designated to receive
notices of application promotion from Test to QA.
4. Packages the artifacts in the outputDeployPackage directory and moves them to a
location only accessible to the Systems Assurance team.

How does the Systems Assurance Team deploy an application to QA

or Production?
1. Critical Step. The Systems Assurance team commits the DeployPackage.zip to
source control and records the build label associated with that artifact. The
Systems Assurance team communicates to the Development Manager the label
assigned to the archived package.

5
 2. Login to the Deployment Manager through the unix shell, WSDMQA1.
3. Copy the DeploymentPackage.zip to the inputDeploymentPackage directory
/webapps/${appname}/inputDeployPackage
4. Run the script processDeployRequest.sh (same name as in the test environment,
but behaves differently when run on the QA Deployment Manager).
5. The application unzips the archive and then executes the tasks necessary to deploy
the application to QA.

How can the Systems Assurance Team Rollback a Deployment?

If the rollback required is for a version immediately prior to the current release run the
script as follows:

processDeployRequest.sh –rollback

This process will then undo the requests made in the DeploymentRequest.xml packaged
in the deployment archive. This rollback only rolls back to the version prior to the last
time the deployment process was executed. For a rollback to a specific version of the
application, the Systems Assurance engineer or the Development Manager will need to
supply the label associated with the DeployPackage archive. And then this file will need
to be retrieved from source control using the label provided. Once the package has been
retrieved, the package will need to be deployed just as if it were a “new” application.

<?xml version="1.0" encoding="UTF-8"?>

<deployment-request>
<deployment-requestor>
<name>Brian McCallion<name>
<email-address>brian_mccallion@bronzedrum.com</email-address>
</deployment-requestor>
<deployment-notification-list>
<environment>test</environment>
<notify-deploy-success>
<email-list>brian_mccallion@bronzedrum.com,
himanshu_pandit@bronzedrum.com</email-address>
</notify-deploy-success>
<notify-deploy-failure>
<email-list>Claudio.torres@bronzedrum.com</email-list>
</notify-deploy-failure>
</deployment-notification-list>
<!--define application install-->
<application>
<application-name>bdcamon</application-name>
<context-root>bdcamon</context-root>
<ear-file-name>bdcamon.ear</ear-file-name>
<install-type>new</install-type>

6
 <strategy-file>strategy.xml</strategy-file>
</application>
<application>
<application-name>bdcconnect</application-name>
<install-type>new</install-type>
<strategy-file>strategy.xml</strategy-file>
</application>
<!--define jar files to deploy to a new or defined shared library-->
<shared-library>
<library-name>testlib</library-name>
<jar-file>test.jar</jar-file>
<jar-file>myjar.jar</jar-file>
</shared-library>
<!--define url-provider-->
<url-provider></url-provider>
<!--define properties to deploy-->
<application-properties>
<property-bundle-name>testgroup1</ property-bundle-name>
<property-file>thisapp.conf</properties-source-location>
<!—zip files of properties will be unzipped and copied to the target location
<properties-target-location>/webapps/bdcamon/properties</properties-target-
location>
</property-bundle-name>
</application-properties>
<!--define sharedXML to deploy-->
<shared-xml>
<xml-bundle-name>testxml</xml-bundle-name>
<xml-file>testxml.zip</xml-file>
<xml-target-location>/webapps/bdcconnect/xml</xml-target-location>
</xml-bundle-name>
</shared-xml>
</deployment-request>

UPM Enterprise Java Bean Deployment Strategy File

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd">
<dfltbndngs>

<module-bindings>

<ejb-jar-binding>
<jar-name>processingserver.jar</jar-name>
<ejb-bindings>

7
 <ejb-binding>
<ejb-name>ProcessorBean</ejb-name>
<jndi-name>ProcessorBean</jndi-name>
</ejb-binding>
</ejb-bindings>
</ejb-jar-binding>

<ejb-jar-binding>
<jar-name>utilserver.jar</jar-name>
<ejb-bindings>
<ejb-binding>
<ejb-name>AuthenticateBean</ejb-name>
<jndi-name>AuthenticateBean</jndi-name>
</ejb-binding>

<ejb-binding>
<ejb-name>EntityLoginBean</ejb-name>
<jndi-name>EntityLoginBean</jndi-name>
</ejb-binding>

<ejb-binding>
<ejb-name>SecurityServiceBean</ejb-name>
<jndi-name>SecurityServiceBean</jndi-name>
</ejb-binding>
</ejb-bindings>
</ejb-jar-binding>

<ejb-jar-binding>
<jar-name>uiserver.jar</jar-name>
<ejb-bindings>
<ejb-binding>
<ejb-
name>UserSessionOriginalXMLCondensedAndCompressedJNDI</ejb-name>
<jndi-
name>UserSessionOriginalXMLCondensedAndCompressedJNDI</jndi-name>
</ejb-binding>

<ejb-binding>
<ejb-
name>UserSessionOriginalXMLCondensedXMLJNDI</ejb-name>
<jndi-
name>UserSessionOriginalXMLCondensedXMLJNDI</jndi-name>
</ejb-binding>

<ejb-binding>
<ejb-name>UserSessionOriginalXMLJNDI</ejb-name>

8
 <jndi-name>UserSessionOriginalXMLJNDI</jndi-name>
</ejb-bindings>
</ejb-jar-binding>

</module-bindings>

</dfltbndngs> </ejb-binding>

BDCConnect URL Provider Deployment Strategy File

<?xml version="1.0"?>
<!DOCTYPE dfltbndngs SYSTEM "dfltbndngs.dtd">
<dfltbndngs>

<module-bindings>

<war-binding>
<jar-name>hello.war</jar-name>
<resource-ref-bindings>
<resource-ref-binding>
<resource-ref-name>url/Startup</resource-ref-name>
<jndi-name>url/BdcIVConfig096</jndi-name>
</resource-ref-binding>
</resource-ref-bindings>
</war-binding>

</module-bindings>

</dfltbndngs>