Sunday, June 24, 2012

ADF Application + Jenkins + WebSphere Application Server

At first sorry for my terrible English. But I hope information I want to share worth it. Please report about mistakes in the post and I'll fix them. If post seems very briefly or there are things you do not understand then write in comments and I'll explain more detailed.



The ADF application, which our department develops, consists of about one hundred projects (one small ear, adf shared libraries, ejb modules, jars with applets). It runs on WebSphere Application Server clusters. And at the moment we support two versions of our application.

The testing process is divided on two parts:
  • when a developer has commited files to the repository, he should check the application is built and runned on the test servers, also he should check all is working properly including his changes;
  • QA phase.
So for developing and supporting of two versions we have six running application instances (three for each version: for developers, for QA department and for support department) on the separate servers. To provide efficient continuous integration process and its easy management I have used Jenkins CI on linux platform.

For this post I'm assuming Jenkins has installed plugins as shown on the picture below.


Computer.

I use an usual computer as a build server. OS is Gentoo Linux.
For speeding up the build process jdeveloper, sources and related files are placed to tmpfs. To do this automatically I've written simple init script and I have added it to the default runlevel.
The filesystem looks like on the image below.
The directory "jenkins" is just a mount point which is used for mounting tmpfs. And the "real_jenkins" folder is a storage with a prepared workspace (jdeveloper, deployment scripts, mount points for WAS servers userlibs). It is used to keep the workspace when the computer is shut down, and when computer starts the contents of the folder is moved to tmpfs.

Jenkins.

Our usual build job in Jenkins looks like in the image below.

 
Extended choise parameter "Applications" is used to update several application instances with the same build artifacts. In this case there is no sence to build the same code twice for QA and support departments separately.



As you can see there are three build steps in the job:
  1. call the ant script to build all projects in the application;
  2. call the ant script to deploy ear file;
  3. call the wsadmin.sh to update the applications on servers;
The ant script build.xml is like this:


Update Applications on servers.

Updating application on the WAS consists of the following steps:
  1. Stop all servers where application is running;
  2. Store context root for webmodules, environment entries for Web modules, environment entries for EJB modules (otherwise they will be overwritten with records stored in the web.xml in the ear.file);
  3. Update application with ear file;
  4. Update application server shared libs (copy jar files from workspace folders into mounted app servers shares);
  5. Restore context root and others described in step 2;
  6. Run application servers.
To do this I've written Jython script for IBM Wsadmin scripting tool which provides all needed functionality:

wsadmin.py you can download here.
Here is an example output of the script:

2 comments:

  1. cobalt vs titanium drill bits
    1 1/3 x 9 1/2 1.2 x 9 1/2 1 1 1/2 1 1/2 1/2 1/2 1/2 1/2 1 1/2 1/2 titanium automatic watch 1/2 1/2 1/2 1/2 1/2 1/2 1/2 titanium joes 1/2 1/2 raw titanium 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 infiniti pro rainbow titanium flat iron 1/2 titanium gravel bike 1/2 1/2 1/2 1/2 1/2 1/2 1/2

    ReplyDelete