Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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.
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.
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.
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.
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>
<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>
<?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>