Even though the deployment process of Websphere Application Server (WAS) is same, still about 80% of the organizations using WAS wastes thousands of dollar in manual administrative costs.

Is Automating Deployment beneficial for you? Yes if

• You have a clustered environment and have multiple applications deployed
• You are wasting valuable administrative time in multiple deployments and administrative and maintenance cost is touching the roof
• You are facing customer dissatisfaction due to manual deployment errors
• You need deployments to be done quickly as low as 3 minutes
• You need status emails to be send with logs after every deployment

Do you have a multi-clustered environment and want to make deployment of EAR automatic?

Do you have managed cell and want to deploy multiple EARs at the same time?

Automated Deployment script is the best solution for you.

Problem:

It is quite easy to deploy (install) an application into a WebSphere Application Server setup using wsadmin script tool but in a real enterprise environment, there are hundreds of interrelated applications spread over dozens of remote application servers, and regular updates that need to be deployed to the right servers, all the while maintaining application availability to users. Even worse, most large enterprises have different sets of operating environments, or stages, each requiring different setups for the same application.

The result might be that at 3 a.m. when some random group of 20 applications has just been rebuilt because of an automated production build of Source Code Management (SCM) code changes, those particular 20 applications each needs to have its updates deployed to its correct individual application server somewhere in the enterprise. And, although it is 3 a.m. in North America , it is prime time elsewhere in the world, so the application updates need to be done in a way that maintains high application availability. This update build and deployment process is regularly repeated, each time involving a randomly different set of updated applications.

Network Deployment Managed Cells, Nodes, and Clusters

Solution:

In this case Automated Deployment script is the right solution for your Enterprise . This script does not need any operator to run. A Cron job can be scheduled to run at specific time to check whether any build is available or not. It also has following capabilities to deploy application in Clustered environment.

The overall automated deployment sequence is

1. Invoke the automated distribution program
   1. This is typically done from an automated system cron job, but may be manually invoked
   2. The invocation command also specifies the stage to be deployed to Read the distribution directory to determine the new application updates to be deployed
2. For each application update, read its stage-specific server targets and application settings
3. From the total set of affected nodes and servers, calculate the subset of unique affected nodes and unique affected servers
4. Pre-validate that the applications and targets and settings are valid
5. Save and then disable AutoSync on all affected nodes
   a. Optionally, you can save and disable SyncOnStartup
6. Install the applications into the Deployment Manager repository:
   a. Set the stage-specific application settings
   b. Set the stage-specific target servers or clusters
7. Sequentially, for each affected node, phase distribute the updates:
   a. Optionally, quiesce all its affected servers (reroute new work requests)
   b. Stop all its affected servers (It will not stop Node)
   c. NodeSync that node to retrieve all updates and install them into the affected servers
   Note : Wait to ensure the EAR expansion is complete
   d. Restart the affected servers
   Note : Test and wait to ensure the server is running
   e. Optionally reactivate the affected servers (to process new work requests)
   f. Optionally validate the installed application operation and request manual confirmation
8. Restore the previous AutoSync settings for all affected nodes
   a. including SyncOnStartup if it was optionally disabled
9. Post-validate all applications
10. Move validated applications into the released directory
    a. If it failed, you can attempt to restore the previously released application
11. Optionally e-mail the deployment log to a notification list

Common Automation script FAQs asked to our Gurus

Q#1. How compatible is this script with different versions of WebSphere Application Servers?

Answer: This Automation Script is designed to work with WebSphere Application Server version 5.0, 5.1, 6.0, 6.1 and 7.0

Q#2 What are the requirements and benefits of this Automation script?

Answer: Automated update deployments are intended to:

• Automatically detect current updates to be deployed
• Automatically read stage-specific targets and application settings
• Optionally, read application requirements (prerequisites, resources, interdependent versions, etc.)
• Minimize failures by pre-validating as much as possible
• Only update affected nodes and affected servers
• Only cycle affected nodes and servers once each (even in the case of many concurrent updates)
• Only cycle one affected node at a time to maximize application availability:
  - Optionally, quiesce affected servers (to allow complex in-progress HTTP sessions to complete)
  - Stop affected servers (to allow server failover and session recovery)
  - NodeSync to retrieve all updates and install them into the affected servers
  - Restart all affected servers
  - Optionally, reactivate affected server if quiesced
  - Minimize the effect of failures by post-validating  

Q#3 Does this Automation script provides the functionality to rollback application to previous version?

Answer: Yes, you can rollback application to previous version by invoking rollback Automation script .

For more information, please dial 1-630-355-6292 (Monday - Friday: 8AM to 6PM), alternatively you can email us at info@websphereguru.net or Contact us and our team of consultants will assist you further